Improved Authentication in Payload

[paulpopus]

Some of this feedback has come from clients or from our devs working with the auth system, here's some ideas:

1. giving admins default controls to re-trigger forgot password emails or email verify emails from the admin panel for the user, something customer support sometimes has to do

2. I would like to see the option of 2FA via OTP (app OR email) supported in core, happy to expand on this for technical implementation

3. email verify process doesn't re-trigger if a user updates their email post verification..you can do a direct update, honestly this feels a bit like a bug

4. ability to revoke all access tokens, in case the password or user's machine is compromised, we should be able to immediately revoke all access tokens

5. If a user is idle on the admin panel, sometimes their session has expired when they come back but the UI makes no indication of this until they try an action like saving a document; instead it should periodically check for access and redirect to the login page

[jasperverbeet]

Hey, as feedback on the auth tokens:

The current setup only provides a single access token that is set in an HTTP-only cookie. The token can be refreshed using that same token. Because the access token is a common JWT, there is no way to revoke it, and using the refresh endpoint the session can be kept alive forever by an attacker.

The HTTP-only cookie helps secure the token, but the default behavior doesn't set the Secure flag. So in the current state, many Payload JWT tokens are vulnerable to MITM attacks. When the token leaks, there is also no way of knowing it leaked and no way to revoke it (aside from rotating the encryption key).

So, tokens can be compromised by MITM attacks and physical device access (and maybe more exotic setups). Both are common enough to worry about.

A common and secure approach is to store the access token in memory and the refresh token in an HTTP-only cookie. The refresh token should be revokable. You can use the jti attr. on a JWT token or issue a totally different encrypted(!) token.

This approach unlocks many security benefits, like letting the user sign out of all sessions manually (including compromised) or automatically (weird location = ban policy). Or you could limit the IP address from where that refresh token is used so compromised tokens could only be used on the same network. There might be less naive implementations, but hopefully, you get my point.

The frontend simply stores 5-15 minute tokens in memory and calls the refresh endpoint when it's expired (using the exp attr.), which will only work if the refresh cookie hasn't expired. Failures log the user out automatically locally.

[aaronksaunders]

For those of use who are not that familiar with everything you just said, usually this just works, can you provide a some references on how to make everything you said above just work correctly and securely?

It sounds like you are saying just using the http only cookie and the refresh endpoint is NOT secure.

[jasperverbeet]

My comment is more on how handling authentication tokens could be improved in a general sense. This work should be done on Payload's side. You should not have to deal with it unless you're piggybacking on their authentication system.

If you seek more generic authentication information, Auth0 is a valuable resource:

https://auth0.com/blog/application-session-management-best-practices/

[aaronksaunders]

Thanks 🙏🏾

…

On Wed, Sep 27, 2023 at 8:29 AM Jasper Verbeet ***@***.***> wrote: My comment is more on how handling authentication tokens could be improved in a general sense. This work should be done on Payload's side. You should not have to deal with it unless you're piggybacking on their authentication system. If you seek more generic authentication information, Auth0 is a valuable resource: https://auth0.com/blog/application-session-management-best-practices/ — Reply to this email directly, view it on GitHub <#3298 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEAFGLYXAVXPHJD5736O2LX4QLZXANCNFSM6AAAAAA4QSYDH4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[renequez]

It would be so cool to replace payload's auth system with better-auth.

[xndyz]

+1 there's already a community member building this https://discord.com/channels/967097582721572934/1339624906438213652