Confirmation token usable only once

[pierrelegall]

I want to use the AshAuthentication.AddOn.Confirmation to send an email with a link to validate the ownership of the email by the user. However, the token is still reusable till the end of its token_lifetime. Note using the token gives the user account access, which makes its reusability questionable in terms of security.

I suppose AshAuthentication.AddOn.Confirmation lack of a:

token_reusable?: [
  type: :boolean,
  doc: "Keep the token reusable after first use or not.",
  default: true # IMO false as default is preferable for security reasons, but it's the current behavior
]

option for this kind of purpose and for security.

FYI, I use the AshAuthentication.Strategy.Password in my use case.

[zachdaniel]

I think to make it not reusable after its first use would require using the token storage feature, and the option to require token presence. Then we can have make single use tokens. But @jimsynz should chime in here as its possible there is something I don't know about this implementation/how its meant to be used.

[pierrelegall]

I think to make it not reusable after its first use would require using the token storage feature, and the option to require token presence.

Seems to be the purpose of the user_tokens table :)

s7_dev=# select * from users_tokens;
         updated_at         |         created_at         |         extra_data         | purpose |     expires_at      |                   subject                    |           jti            
----------------------------+----------------------------+----------------------------+---------+---------------------+----------------------------------------------+--------------------------
 2024-04-05 14:44:35.865993 | 2024-04-05 14:44:35.866007 | {"email": "[email protected]"}  | confirm | 2024-04-08 14:44:35 | user?id=ec81616c-860c-48b6-b4e2-6b42f71427eb | 2v1mivksuqgdssj8k8000di4

[zachdaniel]

Yep! I was just pointing out that it would leverage that feature set. expiring a token can be done without deleting it actually though so we’d just use the existing expiration tooling. So yeah the option you showed would trigger us to expire the token immediately after use.

[pierrelegall]

Or maybe just deleting the users_tokens record after use? Seems more consistent to me.

However, I just notice using a confirmation link of a deleted token in the DB produce an error.

[zachdaniel]

There are cases for deleting them or marking them as expired, depending on what you want. If you want logs of authentication tokens for things like auditing or showing users session history, that kind of thing, you might want that. But I do think we should have an option when configuring it if tokens should be "expired" or "destroyed". We should make confirming a deleted token have a graceful error though. Then you could technically implement this on your own by adding a change to the confirmation action and deletes the token being used.

[jimsynz]

Or maybe just deleting the users_tokens record after use? Seems more consistent to me.

However, I just notice using a confirmation link of a deleted token in the DB produce an error.

I think that the right approach is to revoke the token after it's been used. I can add a change for this. Does it actually need to be configurable or was it just an mistake on my part?

[zachdaniel]

I don't think it needs to be configurable. I don't see a reason why you'd want to allow it to be used again. Also,

Note using the token gives the user account access, which makes its reusability questionable in terms of security.

Seems problematic. Should the token only be usable to confirm and then require re-authentication? Maybe that should be configurable?

[jimsynz]

It's up to the user to implement then auth controller/plug in such a way that it signs in the user or not.

[zachdaniel]

Perhaps our default auth controller example should illustrate that?