• Access and Refresh Tokens are JWT bearer tokens
• AT expires in 5 mins
• RT expires in 3 months
• Auth Service provides token rotation for other services
• Auth Service keeps track of Refresh Tokens and stores them in the database
• In production Auth Service shouldn't have access to users data. This issue can be resolved by providing to the Auth Service appropriate endpoints from user microservice. Here however AS manages user data as well.
• For convenience AT and RT are being sent as json object. Advantage of sending data in headers is that it can be accessed before the body is downloaded, so there's a place for a performance improvement.

1. /login - SPA => Auth Service

   • POST, requires username && password sent in body
   • return AT & RT pair

2. /refresh - Resource Server => Auth Service

   • POST, AT && RT sent in body
   • return new AT && RT pair

3. /verify - Resource Server => Auth Service

   • POST, AT sent in body
   • return boolean

1. Stores Refresh Tokens
2. Columns
   • id
   • tokenstr - token in string form
   • rootId - id of root token used to invalidate a family of tokens
   • refreshed - set to True upon token rotation
3. Improvements
   • tokens expire after 90 days, so whole tokens families could be deleted automatically

1. SPA makes a request to Auth Server's /login endpoint
   1. If login & password combinaction is correct
   • AS responses with jwt access & refresh token pair
   • AS stores RT in database on AS side. DB can't be accessed by ohter services.
   • SPA stores AT + RT in secure storage
   2. Otherwise user is asked to input correct login data.
2. SPA asks Resource Server for sensitive data
   • Access Token is being sent as part of a request (header or body, pros and cons are described in Details section above)
3. Resource Server makes a request to Auth Server's /verify endpoint
   1. AS verifies token and sends response
   2. If token is valid
      • RS responds to SPA with a protected resource
   3. Otherwise RS tries to refresh token

1. Resource Server makes a request to Auth Server's /refresh endpoint (expired AT & valid RT)
   • AS validates both
   • If validation passes RS responds with new AT & RT pair

1. Resource Server makes a request to Auth Server's /refresh endpoint with expired token pair
   • AS responds with 401 unauthorized
2. RS redirects SPA to login screen

1. Malicious user steals Refresh Token from User
2. User continues using SPA
3. RS refreshes AT & RT pair
4. User goes offline
5. Malicious user tries to use stolen RT
6. AS keeps track of previously used tokens and invalidates stolen token and Users newest token.
7. User comes back online
8. User has to log in again due to security breach

From auth0 article:

"Refresh token rotation guarantees that every time an application exchanges a refresh token to get a new access token, a new refresh token is also returned. Therefore, you no longer have a long-lived refresh token that could provide illegitimate access to resources if it ever becomes compromised. The threat of illegitimate access is reduced as refresh tokens are continually exchanged and invalidated."

"It's critical for the most recently-issued refresh token to get immediately invalidated when a previously-used refresh token is sent to the authorization server. This prevents any refresh tokens in the same token family from being used to get new access tokens."

python -m venv .venv
pip install -r requirements.txt
flask --app flaskr --debug run

This repo is just a proof of concept and it's not meant to be run in a production 💀

• https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/