Skip to content

Latest commit

 

History

History
45 lines (28 loc) · 3.33 KB

Notes.md

File metadata and controls

45 lines (28 loc) · 3.33 KB

Understanding Access tokens and Refresh Tokens in JWT

Certainly! Let's consider a real-world scenario for authentication using JSON Web Tokens (JWT), access tokens, and refresh tokens:

Real-World Scenario: User Authentication in a Web Application

1. User Login:

  • A user logs in to a web application by providing their username and password.
  • The server verifies the credentials and, upon successful authentication, generates a JWT containing an access token and a refresh token.

2. Access Token Usage:

  • The server sends the access token back to the client (web browser) after successful login.
  • The client includes the access token in the header of each subsequent request to access protected resources (e.g., user profile, sensitive data).
  • The server validates the access token on each request to ensure the user has the necessary permissions.

3. Access Token Expiry:

  • To enhance security, access tokens have a short lifespan (e.g., 15 minutes).
  • After the access token expires, the client receives a 401 Unauthorized response from the server.

4. Refresh Token Usage:

  • Instead of prompting the user to log in again, the client uses the refresh token.
  • The client sends the refresh token to the server, requesting a new access token.
  • The server validates the refresh token and, if valid, issues a new access token without requiring the user to re-enter their credentials.

5. Refresh Token Security:

  • Refresh tokens have a longer lifespan (e.g., several days).
  • The server securely stores refresh tokens and associates them with the user.
  • If a refresh token is compromised, an attacker could use it to obtain a new access token, so it should be stored securely on the client and transmitted over secure channels.

6. Logout:

  • If a user logs out or if a refresh token needs to be invalidated (e.g., due to a security concern), the server can revoke the refresh token, preventing its future use.

In this scenario, the combination of access tokens for short-lived access to resources and refresh tokens for obtaining new access tokens without re-authentication enhances security. If an access token is compromised, its short lifespan limits the potential harm, and the refresh token's longer lifespan allows for continuous access without frequent user logins.

Question: assume that we are building a full stack application and we have a sinup feature in that so when the client writes the password in the form it is sent to the server(express) in which encryption is done and the encrypted password is stored in database

My question is in between where the password is being sent from client to express server is it not encrypted and still a raw password

When a password is sent from the client to the server, especially in a typical HTTP request, it's generally sent in plain text unless additional security measures are in place. To secure this process, it's common to use HTTPS (SSL/TLS) to encrypt the communication between the client and the server, ensuring that the password is not exposed during transit. This way, even if someone intercepts the communication, they won't be able to easily extract the password.

Once the server receives the password, it can then perform further encryption, like hashing, before storing it in the database for added security.