This is part of a larger series on OAuth 2.0 Threats. The other parts are:
- OAuth 2.0 Threat Model and Security Considerations
- OAuth 2.0 Client Threats
- OAuth 2.0 Authorisation Endpoint Threats
- OAuth 2.0 Token Endpoint Threats
- OAuth 2.0 Refresh Token Threats
- 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.