JWT After user email change

[gonzamoiguer]

I have a situation where I want users to be able to change their emails. But after this is done, if I understand correctly their original JWT token is no longer valid, so everything after that throws a forbidden error. Is their any way to change the user email and get a new token without signing in again, without asking their passwords or store them locally?

Im sorry if this is a more system oriented question rather than payload. Thanks in advanced : )

[jmikrut]

Hey @gonzam88 — yes, your understanding is correct. A workaround for this should probably be worked into the core I think. I have categorized this as Feature Request, and marked it as planned, but I'm not sure when we can get to this. However, we would happily
accept a PR!

The right way to fix this would be in the update operation, we should have a function that runs before afterChange hooks, and performs the following steps:

1. Check to see if collection being updated supports auth
2. Check to see if incoming email data is different from the original doc's data
3. If emails are different, and user is logged in, and the logged in user's email is the same as the original doc's email, we should recreate a token with the new email and set a new cookie with the new token (therefore overriding the old outdated token, and keeping the user logged in).

This code should all be encapsulated in a single function and called from the update collection operation.

Note that in the interim, you could also do this with an afterChange hook. You could look at our refresh operation, which has most / all of the code you would need to do to take in an existing token, decode it, update the email, re-encode it, and then set a new cookie with the token.

Good question!

[thgh]

If a user makes any request and theupdatedAt of the user object is later than the iat of the JWT -> it should refresh the token. Otherwise the parameters from saveToJWT may have changed and there is a mismatch between server & client access() checks.

Assigning a role to someone and than having to tell them to sign out and back in again. It feels buggy.

These lines in refresh() have quite some security implications. As an attacker, I can refresh indefinitely and once I have been assigned a role, I can keep it forever. The industry standard is to have an access token and a refresh token where the access token is valid for a short time (seconds to minutes). That token should only be derived from the database (source of truth), not from a previous JWT.

[wojciechkrol]

Doesn’t this commit resolve the issue of changing the email address of logged user? Right now only token.id is considered.

https://github.com/payloadcms/payload/pull/789/files

[jmikrut]

Ummm, you are awesome.

Yes, for some reason my mind was blanking and I thought that recent PR actually had the opposite effect, but you are 100% right.

@gonzam88 — this should now work with nothing necessary at all. Users should be able to stay logged in.

Phew. I need more coffee!

[gonzamoiguer]

Thanks @jmikrut & @wojciechkrol for the info, very clear. Based from this comment I assume from now on JWT token will not change if the email is changed. Is that right and safe to assume is just a matter of updating to v1.0.9? Thanks!

[jmikrut]

Yep. Update and give it a shot!