Your video series about OAuth 2.0 is great, thank you for your work. Obviously, the token revocation can work only if the resource server performs a token introspection on the auth server. Or maybe there is some particular technique that I am missing?
yes, that's why the token lifetimes should not be too long and for critical actions it is a good practice to ask the user again to log in (e.g. if you make a purchase or so)
could you please explain situations in which a single access token is revoked, without deleting the authorization? and under what circumstances will it be called?
The authorization server will store at least the id of the revoked token. If the protected resource is only validating the token locally (this is possible if it is a self-contained token like a JWT), then there could be a propagation delay. This means that the protected resource would grant access even though the token has been revoked. So unless 1. the protected resource shares some state with the authorization server (which is realistically only feasible if both the authorization server and the protected resource are managed by the same party) or 2. the protected resource used the token introspection endpoint to check if the token is active or 3. the system uses opaque tokens which requires hitting the authorization server for every single request anyway, there could be a propagation delay. This is sort of the downside of structured, self-contained tokens. I have recorded another video about token introspection which I will publish in the future where this is explained.
What do you think about this video?
Let me know in the comments below.
Your video series about OAuth 2.0 is great, thank you for your work.
Obviously, the token revocation can work only if the resource server performs a token introspection on the auth server.
Or maybe there is some particular technique that I am missing?
yes, that's why the token lifetimes should not be too long and for critical actions it is a good practice to ask the user again to log in (e.g. if you make a purchase or so)
could you please explain situations in which a single access token is revoked, without deleting the authorization? and under what circumstances will it be called?
After revoking, we need to store revoked token somewhere, something like blocked tokens table, Am I right? Or there is another solution?
The authorization server will store at least the id of the revoked token. If the protected resource is only validating the token locally (this is possible if it is a self-contained token like a JWT), then there could be a propagation delay. This means that the protected resource would grant access even though the token has been revoked. So unless
1. the protected resource shares some state with the authorization server (which is realistically only feasible if both the authorization server and the protected resource are managed by the same party) or
2. the protected resource used the token introspection endpoint to check if the token is active or
3. the system uses opaque tokens which requires hitting the authorization server for every single request anyway,
there could be a propagation delay. This is sort of the downside of structured, self-contained tokens.
I have recorded another video about token introspection which I will publish in the future where this is explained.
@@jgoebel I read an article jwt should not be used as session management. Hope you will also cover it.
Thanks for content
But the old token is still valid in another microservices untill it expires.
Yes, that's why there is the concept of OAuth token introspection