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?
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?