mirror of
https://github.com/ByteByteGoHq/system-design-101.git
synced 2026-04-11 20:37:24 -04:00
ee4b7305a2
This PR adds all the guides from [Visual Guides](https://bytebytego.com/guides/) section on bytebytego to the repository with proper links. - [x] Markdown files for guides and categories are placed inside `data/guides` and `data/categories` - [x] Guide links in readme are auto-generated using `scripts/readme.ts`. Everytime you run the script `npm run update-readme`, it reads the categories and guides from the above mentioned folders, generate production links for guides and categories and populate the table of content in the readme. This ensures that any future guides and categories will automatically get added to the readme. - [x] Sorting inside the readme matches the actual category and guides sorting on production
47 lines
2.1 KiB
Markdown
47 lines
2.1 KiB
Markdown
---
|
||
title: "Session-based Authentication vs. JWT"
|
||
description: "Understand the key differences between session and JWT authentication."
|
||
image: "https://assets.bytebytego.com/diagrams/0333-what-s-the-difference-between-session-based-authentication-and-jwts.png"
|
||
createdAt: "2024-02-28"
|
||
draft: false
|
||
categories:
|
||
- security
|
||
tags:
|
||
- "Authentication"
|
||
- "JWT"
|
||
---
|
||
|
||
|
||
|
||
Here’s a simple breakdown for both approaches:
|
||
|
||
## Session-Based Authentication
|
||
|
||
In this approach, you store the session information in a database or session store and hand over a session ID to the user.
|
||
|
||
Think of it like a passenger getting just the Ticket ID of their flight while all other details are stored in the airline’s database.
|
||
|
||
Here’s how it works:
|
||
|
||
* The user makes a login request and the frontend app sends the request to the backend server.
|
||
* The backend creates a session using a secret key and stores the data in session storage.
|
||
* The server sends a cookie back to the client with the unique session ID.
|
||
* The user makes a new request and the browser sends the session ID along with the request.
|
||
* The server authenticates the user using the session ID.
|
||
|
||
## JWT-Based Authentication
|
||
|
||
In the JWT-based approach, you don’t store the session information in the session store.
|
||
|
||
The entire information is available within the token.
|
||
|
||
Think of it like getting the flight ticket along with all the details available on the ticket but encoded.
|
||
|
||
Here’s how it works:
|
||
|
||
* The user makes a login request and it goes to the backend server.
|
||
* The server verifies the credentials and issues a JWT. The JWT is signed using a private key and no session storage is involved.
|
||
* The JWT is passed to the client, either as a cookie or in the response body. Both approaches have their pros and cons but we’ve gone with the cookie approach.
|
||
* For every subsequent request, the browser sends the cookie with the JWT.
|
||
* The server verifies the JWT using the secret private key and extracts the user info.
|