Skip to content

0.9.0

Compare
Choose a tag to compare
@igorbenav igorbenav released this 30 Nov 03:38
· 131 commits to main since this release
5b6229f

0.9.0 Summary

 🚀Features

  • JWT Authentication now supports refresh token🎉

📝Docs

🔐JWT Authentication With Refresh Token

The JWT in the boilerplate was updated to work in the following way:

  1. JWT Access Tokens: how you actually access protected resources is passing this token in the request header.
  2. 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.

What's Changed

Full Changelog: v0.8.3...v0.9.0