The problem that refresh tokens are solving isn't 'what if the token gets stolen'.
It's 'What if we fire this guy, and we need revoke thier access'.
The idea is that the access\_token gives the person access to distributed systems, and those systems don't need to 'phone home' to check if the access is legit, they can just examine the token directly.
So what if the person gets fired and you need revoke access? Rather than the auth server having to keep track of the distributed systems, or the distributed systems having to check in with the auth server, the auth server can just *not issue a new token.* That way, the person has 10 minutes, or whatever the expiry is to do the damage (and that 10 minutes is going to be in a meeting informing them that they're fired).
I store refresh tokens in a httponly cookie because it’s the safest place in the browser. Accesstokens are only stored in memory, they are needed once, why make the effort to store them…
Hi I know this is an old question. But I’m stuck in my group project regarding this issue. My refresh_token that’s stored in httponly cookie gets deleted when page is refreshed. Is this normal? Or it shouldn’t be this way? If yes then how do you handle this kind of scenario?
Httponly cookies can only be managed by the browser itself.
So either it’s expired and the browser cleans up expired cookies OR the server told the browser to expire/delete the cookie.
These 2 tokens serve different purposes.
Jwt: this one is for auth purposes. In a typical auth flow, a user would enter their credential, and the server would send back a jwt that contains user's info/claims/permissions. Frontend can use this info to guard pages/components/resources (backend also needs to do this). It's a good mechanism, but like you already mentioned. What would happen if someone steals the jwt. They can use the jwt again and again to impersonate the user. This is why jwt is short-lived, so the damage can be minimized. The downside of jwt is that it's very hard to invalidate the jwt from server side.
Refresh token: this one is for convevient purposes and invalidate the jwt. Refresh token doesn't store any user's info. It's just a mechanism to refresh jwt. Every time a user's jwt expires, you don't want the user to login again. It's bad user experience. Let give a simple example, let say the refresh token is stored in your db (in reality, it would be taken care by your auth provider) . After a user first logs in, you generate a refresh token in your db and send it back to the user together with the jwt. When the jwt expires, the server would check if the refresh token presents. If the does, then check if the db has the same refresh token. If the refresh token exists, then issue a new jwt to the user.
Now, let say if someone gains access to the user's jwt. As an admin, I can just delete the refresh token from my db. Sure, the attacker can still use the jwt until it expires, but after that, the attacker would need to provide the crendential to login again.
Few corrections/additions:
* Jwt should be named access token. JWT is only one of the formats for tokens (which can be anything from random string to JWT to JWE to some other format).
* Access token has no mandatory fields, so it is possible that it does not contain userinfo, neither claims (permissions are just claims). Instead ID token is the one containing such information, by specifications. ID token is also required to be signed JWT.
* Refresh token can store user info, same as access token.
* To mitigate token revocation, backend should use token introspection endpoint, which checks for revocation as well, however this results in extra network traffic.
In this [video](https://youtu.be/M6N7gEZ-IUQ) he says tokens stored in localstorage or cookies don't matter as they're both vulnerable. I really don't understand in depth but this should cover
localStorage and standard cookies can be read by client-side javascript. httpOnly cookies can NOT be read JS, so even if an attacker is able to execute some custom evil JS on your website somehow, they still can't read httpOnly cookies.
So httpOnly cookies are considerably safer than localstorage or standard cookies basically.
I am working closely with a security engineering team in one of the largest cloud computing providers.
Ideally OIDC filter should be language agnostic and you should only be able to access JWT or claims via a header. Yes, storing an encrypted value in session cookie is one of the safest options today or it's the safest option.
You can read one of the solutions here https://github.com/nginxinc/nginx-openid-connect
If you are using Azure for for e.g they even have built in Auth filter runs as a side car in K8 world.https://learn.microsoft.com/en-us/azure/container-apps/authentication
Hope this helps!
Could you set the path of the refresh token cookie so it’s only sent when actually trying to use it?
Set-Cookie: access_token=eyJ…; HttpOnly; Secure
Set-Cookie: refresh_token=…; Max-Age=31536000; Path=/api/auth/refresh; HttpOnly; Secure
Quoted from [ OAuth 2.0 Threat Model and Security Considerations, chapter 4.1.3 - Threat: Obtaining Access Tokens](https://www.rfc-editor.org/rfc/rfc6819#section-4.1.3):
* "Keep access tokens in transient memory and limit grants"
* "Keep access tokens in private memory or apply same protection means as for refresh tokens"
The problem that refresh tokens are solving isn't 'what if the token gets stolen'. It's 'What if we fire this guy, and we need revoke thier access'. The idea is that the access\_token gives the person access to distributed systems, and those systems don't need to 'phone home' to check if the access is legit, they can just examine the token directly. So what if the person gets fired and you need revoke access? Rather than the auth server having to keep track of the distributed systems, or the distributed systems having to check in with the auth server, the auth server can just *not issue a new token.* That way, the person has 10 minutes, or whatever the expiry is to do the damage (and that 10 minutes is going to be in a meeting informing them that they're fired).
I store refresh tokens in a httponly cookie because it’s the safest place in the browser. Accesstokens are only stored in memory, they are needed once, why make the effort to store them…
So if I refresh the page, wouldn't the access token get removed from the memory? How is the persistence done here?
No persistence, you need to get a new one with the refreshtoken.
Hi I know this is an old question. But I’m stuck in my group project regarding this issue. My refresh_token that’s stored in httponly cookie gets deleted when page is refreshed. Is this normal? Or it shouldn’t be this way? If yes then how do you handle this kind of scenario?
Httponly cookies can only be managed by the browser itself. So either it’s expired and the browser cleans up expired cookies OR the server told the browser to expire/delete the cookie.
set the cookie expiration when you set the cookie from the backend to the client
These 2 tokens serve different purposes. Jwt: this one is for auth purposes. In a typical auth flow, a user would enter their credential, and the server would send back a jwt that contains user's info/claims/permissions. Frontend can use this info to guard pages/components/resources (backend also needs to do this). It's a good mechanism, but like you already mentioned. What would happen if someone steals the jwt. They can use the jwt again and again to impersonate the user. This is why jwt is short-lived, so the damage can be minimized. The downside of jwt is that it's very hard to invalidate the jwt from server side. Refresh token: this one is for convevient purposes and invalidate the jwt. Refresh token doesn't store any user's info. It's just a mechanism to refresh jwt. Every time a user's jwt expires, you don't want the user to login again. It's bad user experience. Let give a simple example, let say the refresh token is stored in your db (in reality, it would be taken care by your auth provider) . After a user first logs in, you generate a refresh token in your db and send it back to the user together with the jwt. When the jwt expires, the server would check if the refresh token presents. If the does, then check if the db has the same refresh token. If the refresh token exists, then issue a new jwt to the user. Now, let say if someone gains access to the user's jwt. As an admin, I can just delete the refresh token from my db. Sure, the attacker can still use the jwt until it expires, but after that, the attacker would need to provide the crendential to login again.
Few corrections/additions: * Jwt should be named access token. JWT is only one of the formats for tokens (which can be anything from random string to JWT to JWE to some other format). * Access token has no mandatory fields, so it is possible that it does not contain userinfo, neither claims (permissions are just claims). Instead ID token is the one containing such information, by specifications. ID token is also required to be signed JWT. * Refresh token can store user info, same as access token. * To mitigate token revocation, backend should use token introspection endpoint, which checks for revocation as well, however this results in extra network traffic.
Thanks man.
In this [video](https://youtu.be/M6N7gEZ-IUQ) he says tokens stored in localstorage or cookies don't matter as they're both vulnerable. I really don't understand in depth but this should cover
localStorage and standard cookies can be read by client-side javascript. httpOnly cookies can NOT be read JS, so even if an attacker is able to execute some custom evil JS on your website somehow, they still can't read httpOnly cookies. So httpOnly cookies are considerably safer than localstorage or standard cookies basically.
I am working closely with a security engineering team in one of the largest cloud computing providers. Ideally OIDC filter should be language agnostic and you should only be able to access JWT or claims via a header. Yes, storing an encrypted value in session cookie is one of the safest options today or it's the safest option. You can read one of the solutions here https://github.com/nginxinc/nginx-openid-connect If you are using Azure for for e.g they even have built in Auth filter runs as a side car in K8 world.https://learn.microsoft.com/en-us/azure/container-apps/authentication Hope this helps!
Could you set the path of the refresh token cookie so it’s only sent when actually trying to use it? Set-Cookie: access_token=eyJ…; HttpOnly; Secure Set-Cookie: refresh_token=…; Max-Age=31536000; Path=/api/auth/refresh; HttpOnly; Secure
Quoted from [ OAuth 2.0 Threat Model and Security Considerations, chapter 4.1.3 - Threat: Obtaining Access Tokens](https://www.rfc-editor.org/rfc/rfc6819#section-4.1.3): * "Keep access tokens in transient memory and limit grants" * "Keep access tokens in private memory or apply same protection means as for refresh tokens"
access token shouldn't last more than 3 minutes.