This is a nice overview, and I always find straightforward pros/cons lists useful. However, I would highly recommend against the practice of letting clients expect a non-opaque token for sessions; if you don’t, then you risk ending up in the scenario where it’s difficult to migrate to a new token type without breaking clients. I would instead suggest taking the OIDC approach where the session (access) token is opaque, but is paired with a non-opaque ID token. You can still use a JWT for the session token for scalability (to avoid DB lookups), but this allows you to decouple the session management from profile information which allows you to update your session management independently if necessary.
Following on from that, I think the following cons to using JWTs for session management are also worth mentioning:
Con: Clients need to implement state management for tokens: With JWTs and refresh tokens, clients need to have a mechanism for retrieving, storing, querying and refreshing the active token in a scalable (for their codebase) way. This mechanism is usually simple enough to implement, but can be tricky to integrate cleanly into a codebase (since it’s often a global dependency), and I’ve seen a number of projects suffer from subtle bugs from incorrect session management.
Con: Using fields correctly: From my understanding, a lot of the criticism of JWTs doesn’t necessarily come from their inherent insecurity, but the fact that they provide a lot of opportunity for misuse. In the case of the exported fields, there is twice as much opportunity for misuse, because not only does the client need to handle the fields correctly, but the server needs to implement them correctly. For example, are they issuing the correct audience value? Is the jti field unique? Is the sub unique, and immutable for that subject? This is ideally mitigated by using well-tested libraries, tools and services, but because of the perceived ease of use of JWTs it’s not uncommon for people to try and roll their own handling for them.
It is recommended that the client should not have access to the access token (to avoid theft via XSS). This means that whatever the token type, it should not affect the client (even if the token type changes). Even when using OIDC tokens, one can still use JWT access tokens to get the scalability benefit. If using opaque access tokens, the API will have to query a db regardless of whether an OIDC token is being used.
Thank you for the two additional cons! Do you have any examples of codebases that have tried to implement the refresh token way, but did so incorrectly?
This is a nice overview, and I always find straightforward pros/cons lists useful. However, I would highly recommend against the practice of letting clients expect a non-opaque token for sessions; if you don’t, then you risk ending up in the scenario where it’s difficult to migrate to a new token type without breaking clients. I would instead suggest taking the OIDC approach where the session (access) token is opaque, but is paired with a non-opaque ID token. You can still use a JWT for the session token for scalability (to avoid DB lookups), but this allows you to decouple the session management from profile information which allows you to update your session management independently if necessary.
Following on from that, I think the following cons to using JWTs for session management are also worth mentioning:
Con: Clients need to implement state management for tokens: With JWTs and refresh tokens, clients need to have a mechanism for retrieving, storing, querying and refreshing the active token in a scalable (for their codebase) way. This mechanism is usually simple enough to implement, but can be tricky to integrate cleanly into a codebase (since it’s often a global dependency), and I’ve seen a number of projects suffer from subtle bugs from incorrect session management.
Con: Using fields correctly: From my understanding, a lot of the criticism of JWTs doesn’t necessarily come from their inherent insecurity, but the fact that they provide a lot of opportunity for misuse. In the case of the exported fields, there is twice as much opportunity for misuse, because not only does the client need to handle the fields correctly, but the server needs to implement them correctly. For example, are they issuing the correct audience value? Is the
jtifield unique? Is thesubunique, and immutable for that subject? This is ideally mitigated by using well-tested libraries, tools and services, but because of the perceived ease of use of JWTs it’s not uncommon for people to try and roll their own handling for them.Hi Seán! Thank you for the detailed response!
It is recommended that the client should not have access to the access token (to avoid theft via XSS). This means that whatever the token type, it should not affect the client (even if the token type changes). Even when using OIDC tokens, one can still use JWT access tokens to get the scalability benefit. If using opaque access tokens, the API will have to query a db regardless of whether an OIDC token is being used.
Thank you for the two additional cons! Do you have any examples of codebases that have tried to implement the refresh token way, but did so incorrectly?
Unfortunately not, these were usually in proprietary systems.
Alright, thank you either way.
If you get a chance to evaluate supertokens, we'd love to hear your thoughts and feedback. Would you consider using it for your app?