Tokenfornyelse

Tokenfornyelse is the process of obtaining a new access token after the previous one has expired, enabling continued access to protected resources without requiring the user to re-authenticate. In many authentication systems, this is achieved using a refresh token together with an access token.

In OAuth 2.0 and OpenID Connect, an authorization server issues an access token (short-lived) and a refresh token (longer-lived) to the client after initial authentication. When the access token expires, the client makes a request to the token endpoint with grant_type=refresh_token, presenting its credentials and the refresh token. If valid, the server returns a new access token and, often, a new refresh token. This rotation helps limit the impact of a leaked refresh token and supports seamless user experience.

Security considerations are central to tokenfornyelse. Refresh tokens should be stored securely and bound to the device or application. Shorter access token lifetimes reduce risk at the cost of more frequent renewals. Implement refresh token rotation, revocation mechanisms, and monitoring for unusual usage. Re-authentication may be required if the refresh token is revoked, expired, or otherwise invalidated.

Variants and scope may influence how renewal occurs. Some deployments require offline_access to obtain a refresh token for long-running access. Public clients, such as native or single-page applications, often use PKCE to mitigate risks. In other systems, renewal can be achieved through session cookies or single sign-on rather than refresh tokens, depending on the architecture.

See also: OAuth 2.0, OpenID Connect, access token, refresh token, JWT, token rotation.