91d47680 authorisation

OAuth 2.0 Refresh Token Threats

This is part of a larger series on OAuth 2.0 Threats. The other parts are:

  1. OAuth 2.0 Threat Model and Security Considerations
  2. OAuth 2.0 Client Threats
  3. OAuth 2.0 Authorisation Endpoint Threats
  4. OAuth 2.0 Token Endpoint Threats
  5. OAuth 2.0 Refresh Token Threats
  6. OAuth 2.0 Protected Resource Threats

The OAuth 2.0 refresh token was a bit controversial. It allows long-lived impersonation and recreation of access tokens (with the same or reduced scope). An attacker gaining access to a refresh token has more time, more lattitude than simply obtaining an access token.

The defense for refresh tokens is similar to the other endpoint threats: always use TLS, use a public Certificate Authority, never allow insecure mode.

Like other tokens it is common practice in an OAuth 2.0 server to store them in a persistent database. This might be a Key-Value store like Redis, it might be a RDMS like Postgresql. If these systems are breached (e.g. a backup is lost, etc), you have inadvertently given access to your entire universe.

Refresh tokens can take many implementation-specific forms. The most common form may be a JWT, but, other handle-based designs could be used which could be susceptible to guessing.

As with the other client threats, watch the storage.