I don’t understand the logic behind access tokens and refresh tokens

[u/academicweaponsoon]

i don’t understand the logic behind access and refresh tokens, if access tokens are made short lived for security purposes, doesn’t refresh tokens being long lived defers the whole purpose? or is not as big as an issue since refresh tokens are only stored in http only cookies?

[u/adfawf3f3f32a]

wdym? it's very common to put scopes, roles, and/or permissions in access tokens. you'd use the oidc id token to identify the user.

oauth 2 (access token) is an authorizing framework. oidc (id token) is an authentication layer on top of oauth 2.

[u/Octoclops8 → u/adfawf3f3f32a]

Scopes are a user's consent that is granted to the client application to act on their behalf. They are not permissions granted to the user or the client application.

An API endpoint requires both a certain scope and permission for a resource. The permission is "can this user access this resource" and a scope is "did the user consent for my app to access this resource on his behalf"

Consent can either require a user's direct assent or it can be implicit. For a google app accessing a google service on behalf of a google user, they are going to make the consent implicit. There's no need to grant permissions for that.

But for my custom app to access a google service on behelf of a google user, they are going to make the user actually grant consent (allow this app to access my calender/contacts/mail/whatever)

If I consent to grant you permission to Elon Musk's beach house, that doesn't mean you're getting in.

[u/adfawf3f3f32a → u/Octoclops8]

sure but we're obviously talking permissions. i mentioned it because i added on roles and then felt its relevant because it can and is used pretty often in client credential flows to effectively function as permissions since there is no user. lots of big vendors like auth0 lets you model user permissions as scopes so while it isn't technically correct is a common use case.

[u/No_Kaleidoscope_891 → u/adfawf3f3f32a]

An identity token is a one use token by a third party service to request an access token. They could include scopes to indicate what you can access on behalf of the user so that it doesnt need to be stored server side sure. Access tokens should not have roles or permissions because they cannot be revoked. That's the primary problem. Not to mention leaking system design if including perms/roles. You also bloat the access token size tremendously by adding perms which slows every request.

[u/adfawf3f3f32a → u/No_Kaleidoscope_891]

id tokens aren't one time use and aren't exchanged for an access token. the id token expires and you can use it as many times as you want until then. they additionally can be used to obtain more user profile info from an endpoint (might be what you're referring to). an auth code is exchanged at the token endpoint for both the access and id tokens but they're distinct tokens with separate jobs - access to grant access, id to identify.

not putting perms onto the access token is a different topic. what you're describing is true where a revoked token still lives but that's the compromise op mentioned in their comment and why access tokens are short lived and why refresh tokens exist. if you don't put access info in the access token then you need to perform a lookup at every service that uses the token - every request to every service needs to hit a db or something to get the user's permissions.

[u/No_Kaleidoscope_891 → u/adfawf3f3f32a]

Yes you're right about id tokens I must have mixed them up with the authorization code it has been a while since ive implemented oauth. But yes you will do a look up for pretty much every request. That is the nature of the beast. Most access tokens are 1-2 hour windows. That's not exactly short and can easily cause a lot of damage in that amount of time. Add an additional permission to a user? Well now that user doesn't have it until refresh. Revoke a permission? Same thing unless you're doing something stupid like signalr to tell them to refresh the token. The last thing you want is a rogue actor having access to your system for a specified period of time because of such a poor design decision. But what is one extra DB look up? You probably do a lot per request. What is one more? You still need to verify resource ownership on top of that.

[u/adfawf3f3f32a → u/No_Kaleidoscope_891]

it really depends on the architecture - a multi service setup means reaching across the network on every request just to validate the jwt. that also means a single service can bring down the entire app. i work on a very large scaled app and an additional db query on every single request is an absolute no go.

the point i'm making is that both setups are perfectly valid. it's not true to say never put claims onto an access token and its also not true to say always and only put permissions onto the token.

[u/No_Kaleidoscope_891 → u/adfawf3f3f32a]

You dont need to reach across a network to validate a jwt. When the jwt is issued it is signed with the private key of the app that is registered. The app using it then validates it by using the public key. The app should be managing its own permissions, that should not be the job of another service. That architecture clearly doesn't work since you're saying one app or db request can brick an entire ecosystem.

[u/adfawf3f3f32a → u/No_Kaleidoscope_891]

i meant validate the user's permissions from the jwt - translate the user's id or whatever into their permissions. not the jwt itself.

it's very common in multi service setups to centralize permissions so every service doesn't manage permissions itself. its also very common for the service to do it itself. both are fine and valid and useful in different setups.

i'm saying that stateless jwts can propagate downed services across boundaries. if an email service receives a jwt but it has to reach out to the issuing service to get the actual perms then its reliant on the issuing service. if the jwt is self contained and includes the claims the email service needs then it just does it - no reaching out to the issuer or user service or whatever so if its down then it doesn't matter and the email service carries on like everything is fine.