# OAuth 2.0 Refresh Token Threats

- Link: https://www.agilicus.com/oauth-2-0-refresh-token-threats/
- Published: 2021-01-13T06:00:00+00:00
- Author: Don Bowman

This is part of a larger [series](https://www.agilicus.com/oauth-2-0-threat-model-and-security-considerations)
on OAuth 2.0 Threats. The other parts are:

 1. [OAuth 2.0 Threat Model and Security Considerations](https://www.agilicus.com/oauth-2-0-threat-model-and-security-considerations/)
 2. [OAuth 2.0 Client Threats](https://www.agilicus.com/oauth-2-0-threat-model-and-security-considerations-1)
 3. [OAuth 2.0 Authorisation Endpoint Threats](https://www.agilicus.com/oauth-2-0-authorisation-endpoint-threats/)
 4. [OAuth 2.0 Token Endpoint Threats](https://www.agilicus.com/oauth-2-0-token-endpoint-threats/)
 5. [OAuth 2.0 Refresh Token Threats](https://www.agilicus.com/oauth-2-0-refresh-token-threats/)
 6. [OAuth 2.0 Protected Resource Threats](https://www.agilicus.com/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](https://www.agilicus.com/jwt-token-is-you-on-the-wire/), but, other
handle-based designs could be used which could be susceptible to guessing.

As with the other client threats, watch the storage.