...
Refresh tokens would allow a 3rd party client to request a new access token from Synapse. This enables OAuth clients to have long-lived access to a user’s identity and resources. Refresh tokens are an optional component defined in the OAuth 2.0 specification (https://tools.ietf.org/html/rfc6749#section-1.5).
Use Cases for Refresh Tokens
...
Client-centric token revocation is defined in RFC 7009https://tools.ietf. org/html/rfc7009. From the RFC:
From an end-user's perspective, OAuth is often used to log into a certain site or application. This revocation mechanism allows a client to invalidate its tokens if the end-user logs out, changes identity, or uninstalls the respective application. Notifying the authorization server that the token is no longer needed allows the authorization server to clean up data associated with that token (e.g., session data) and the underlying authorization grant. This behavior prevents a situation in which there is still a valid authorization grant for a particular client of which the end-user is not aware. This way, token revocation prevents abuse of abandoned tokens and facilitates a better end-user experience since invalidated authorization grants will no longer turn up in a list of authorization grants the authorization server might present to the end-user.
...
This section covers implementation details that will not be visible to users of the new services, and is not necessary to read to have an understanding of how to use the new services.
To support revoking access refresh tokens, we will need to track them in the database. As mentioned earlier, we can trace access tokens to a refresh token by adding a refresh token ID to the access token as a JWT claim. By doing this, we only need to store records of refresh tokens in the database.
We hash the token to reduce the severity of tokens being exposed. It is proposed that tokens will be randomly generated, and then hashed using SHA256, but changing this is open to discussion.
New DB Table: OAUTH_REFRESH_TOKENS
...