Reputation: 183
I understand that access tokens are not saved at the server side (usually) and are just verified using some key an algorithm. However, it seems that the normal behavior is to save a refresh token in the server side(i.e:database) and compare it with the user's when the user is trying to refresh their access token. My question is why not just verify the refresh token the same way the access token was verified?
Upvotes: 0
Views: 822
Reputation: 5279
It is generally more secure if a token is an ID that is validated against a database, as this allows the token to be revoked at any time (by removing it from the database or marking it as invalid).
Self-validating tokens, such as JWTs, cannot be revoked (without using a database, which defeats most of the benefits of using self-validating tokens) - they can only expire. Therefore, they should have a short expiry time. The benefit of self-validating tokens is not only performance, but also eliminating dependencies, as the resource server does not need to connect to a database owned by the authorization server. Instead it can simply validate the tokens by itself, using a trusted public key.
Using a database is also easier to implement, as most web apps already have one anyway, and self-validating tokens are easy to do wrong (there are many JWT libraries out there that have flaws or bad defaults).
The refresh token is only used to request a new access token, so performance is not important. The request is sent to the authorization server, which "owns" any authorization-related database(s), so it does not add any unwanted dependencies.
Note that access tokens do not have to be self-validating tokens. It is perfectly fine if they are also simply IDs validated against a database. The separation between access token and refresh token only makes it possible to choose an implementation using self-validating access tokens.
Upvotes: 1