The JWT in the boilerplate was updated to work in the following way:
JWT Access Tokens: how you actually access protected resources is passing this token in the request header.
Refresh Tokens: you use this type of token to get an access token, which you'll use to access protected resources.
The access token is short lived (default 30 minutes) to reduce the damage of a potential leak. The refresh token, on the other hand, is long lived (default 7 days), and you use it to renew your access token without the need to provide username and password every time it expires.
Since the refresh token lasts for a longer time, it's stored as a cookie in a secure way:
# app/api/v1/login
...
response.set_cookie(
key="refresh_token",
value=refresh_token,
httponly=True, # Prevent access through JavaScript
secure=True, # Ensure cookie is sent over HTTPS only
samesite='Lax', # Default to Lax for reasonable balance between security and usability
max_age=<number_of_seconds> # Set a max age for the cookie
)
...
You may change it to suit your needs. The possible options for samesite are:
Lax: Cookies will be sent in top-level navigations (like clicking on a link to go to another site), but not in API requests or images loaded from other sites.
Strict: Cookies will be sent in top-level navigations (like clicking on a link to go to another site), but not in API requests or images loaded from other sites.
None: Cookies will be sent with both same-site and cross-site requests.
🚀Usage
What you should do with the client is:
Login: Send credentials to /api/v1/login. Store the returned access token in memory for subsequent requests.
Accessing Protected Routes: Include the access token in the Authorization header.
Token Renewal: On access token expiry, the front end should automatically call /api/v1/refresh for a new token.
Login Again: If refresh token is expired, credentials should be sent to /api/v1/login again, storing the new access token in memory.
Logout: Call /api/v1/logout to end the session securely.
This authentication setup in the provides a robust, secure, and user-friendly way to handle user sessions in your API applications.
🔐JWT Authentication With Refresh Token
Details
The JWT in the boilerplate was updated to work in the following way:
access token, which you'll use to access protected resources.The
access tokenis short lived (default 30 minutes) to reduce the damage of a potential leak. Therefresh token, on the other hand, is long lived (default 7 days), and you use it to renew youraccess tokenwithout the need to provide username and password every time it expires.Since the
refresh tokenlasts for a longer time, it's stored as a cookie in a secure way:You may change it to suit your needs. The possible options for
samesiteare:Lax: Cookies will be sent in top-level navigations (like clicking on a link to go to another site), but not in API requests or images loaded from other sites.Strict: Cookies will be sent in top-level navigations (like clicking on a link to go to another site), but not in API requests or images loaded from other sites.None: Cookies will be sent with both same-site and cross-site requests.🚀Usage
What you should do with the client is:
Login: Send credentials to/api/v1/login. Store the returned access token in memory for subsequent requests.Accessing Protected Routes: Include the access token in the Authorization header.Token Renewal: On access token expiry, the front end should automatically call/api/v1/refreshfor a new token.Login Again: If refresh token is expired, credentials should be sent to/api/v1/loginagain, storing the new access token in memory.Logout: Call /api/v1/logout to end the session securely.This authentication setup in the provides a robust, secure, and user-friendly way to handle user sessions in your API applications.