The key to systems with separate Access and Refresh tokens is that they involve three parties:

• The client that wants to access some service
• The service they want to access
• A separate service which is in charge of authentication

Access Tokens are sent between the client and the service being accessed. They may even be passed around multiple services.

To keep things efficient, they may be stateless tokens such as JWT – the authorization data is encoded in the token itself in a tamper-proof way, so no access to a central database is needed to check the token. This comes with a cost: if the token leaks, an attacker can continue to use it. This means such tokens need to have a short lifetime – maybe even less than a minute, if the service is particularly sensitive.

The Refresh Token is how the client gets a new Access Token from the authentication server without asking the user for their login details every time. It is held closely by the client, and only ever sent back to the authentication server.

Unlike the Access Tokens, which are passed around many stateless services, Refresh Tokens have a stateful element on the authentication server – specifically, it can revoke tokens. That means that although the Refresh Token has a much longer lifespan than the Access Token, an attacker cannot use a compromised token indefinitely – the authentication server can detect suspicious behaviours, like the same Refresh Token being used more than once, and refuse to issue new Access Tokens without a fresh login. Similarly, it can check that the user still has permission for the requested resource, and hasn’t been suspended, or explicitly requested a logout.

The lifetime of the Refresh Token also acts as a measure of the maximum idle time before the user must re-authenticate, like the timeout on a stateful session. For instance, a Refresh Token lifetime of 1 hour means the user can log in, walk away for 59 minutes, and then come back; the client will no longer have any valid Access Tokens, but the Refresh Token will still be accepted, so the user doesn’t have to log back in.

The two tokens allow you to have a different balance of competing requirements: the efficiency and reasonable security of a short-lived stateless token, and the user-friendliness and reasonable security of a long-lived stateful token.

You don’t have to use refresh tokens. The client could ask for username/password every time (which is annoying to the end user), or store the credentials, with the risk of leaking them. Passwords are often reused, so leaking one is rather dangerous. A refresh token is only valid for a single API, has a limited validity period (which can be controlled by the authentication server), can be invalidated without resetting someone’s password. So it’s a lot safer to store than a password.

One key advantage of refresh tokens that’s being missed is that they are revokable, while the access token is not.

To authenticate the access token, only its signature is checked. This makes it extremely fast to authenticate, and allows authentication to be performed in a distributed manner by different services without needing to check with another server or database. This also means it needs to have a short expiration time in case it’s compromised because it can’t be revoked.

With refresh tokens, it’s presumed that some database or authentication server needs to be contacted in order to generate a new access token. This means it’s slow (relatively) and can’t be done in a distributed manner. But the token can be revoked if the user account is compromised, or the user changes their password, or for any other reason.

If you want to just use an access token/api key you can. It just means you either have to lookup in a database to make sure the token is still valid, or set a short refresh rate and force the client to re-authenticate every time. If your application doesn’t need the performance, or can tolerate re-authenticating frequently, or you don’t care about revoking access tokens, then you don’t need refresh tokens.