forked from supabase/auth
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: add idempotent refresh token algorithm (supabase#1278)
Modifies the refresh token algorithm to support a limited form of idempotency. The lack of this behavior is documented to cause loss of session. **Problem** GoTrue, so far, assumes that clients calling the `POST /token?grant_type=refresh_token` endpoint are guaranteed to at least save the result of the response. Like all networked software, there are no guarantees that the sender of a request will receive the response, or act on it. This problem is exacerbated by network appliances like CDNs and reverse proxies which mask the TCP stream semantics from GoTrue. A properly closed TCP stream does not mean that the receiver of the response received the stream, but rather that a proxy in the chain buffered the response. Furthermore, even if the receiver is able to receive _and parse_ the response, usually there are no guarantees that it will continue processing the response. With refresh tokens, it's incredbily important that the receiver successfully persists the new refresh token to durable storage. There are no guarantees of this as browsers and mobile apps (and the computers they run on) can die, go offline or just malfunction between sending a request and processing its response. **Solution** There are really only two solutions to this problem: 1. Idempotency. Where for the same inputs the same output is generated. 2. Double-commit. Where the receipt of the response needs to be acknowledged before the state changes. We considered a double-commit protocol, but decided against it at this time as it introduces quite a bit of complexity. We may turn to it if the limited idempotency solution does not cover a sufficient number of the cases in real-world testing. **Changes** The refresh token algorithm is changed to offer a limited form of idempotency, such that: 1. An **active refresh token** is the last non-revoked refresh token in a session. This is the token that should have been saved by the client. It can generally be only used once to generate a new active refresh token at which point it looses its status. 2. A non-active refresh token can sometimes be used again to issue a valid token: 2.1. If the non-active token is being _reused_ close to the time it was used again. 2.2. **NEW** If the non-active token is the parent of the currently active token. This case adds limited idempotency by always returning the active token, and does not create a new active refresh token.
- Loading branch information
Showing
4 changed files
with
108 additions
and
26 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters