# OAuth 2.0 Refresh Token Threats

This is part of a larger [series](/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](/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.