Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Token refresh #63

Merged
merged 2 commits into from
Nov 30, 2023
Merged

Token refresh #63

merged 2 commits into from
Nov 30, 2023

Conversation

igorbenav
Copy link
Owner

🔐JWT Authentication With Refresh Token

Details

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.

@igorbenav igorbenav added the enhancement New feature or request label Nov 30, 2023
@igorbenav igorbenav self-assigned this Nov 30, 2023
@igorbenav igorbenav merged commit 5b6229f into main Nov 30, 2023
@igorbenav igorbenav deleted the token-refresh branch November 30, 2023 03:32
@igorbenav igorbenav mentioned this pull request Nov 30, 2023
15 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant