It's an open standard (RFC 7519) for creating a compact and self-contained way to securely transmit information between parties as a JSON object.
JWT is a standard used to create access token for an application
JWT is Authentication service to authenticate user
working
Client application authenticates with the server.
Server generates a JWT token containing user information and claims/user identity, and sends it to the client..
Client stores the token securely (e.g., cookies, local storage).
Then when client request something from server. Client includes the token with subsequent requests to the server.
Server verifies the token's signature and validity.
Server grants access based on the user information and claims in the token.
Use Case
Single Sign-On (SSO): Allows users to log in once and preserve their session information to access multiple applications.
Single Sign-On (SSO):
SSO enables users to log in once and preserve their session information access multiple applications without re-entering credentials.
However, JWTs don't directly store session information locally. Instead, they facilitate SSO by:
Carrying user identity and authentication information across different applications within a federated system.
Eliminating the need for each application to independently authenticate the user.
This creates a seamless login experience for the user.
API Authentication:
- You're correct that JWTs provide secure access to APIs by verifying user identity. They act as secure tokens that APIs can trust to authenticate requests.
Data Exchange:
JWTs can indeed be used for secure data exchange between applications by carrying encrypted or signed data within their payload.
This ensures the confidentiality and integrity of the data being shared.
Key Points:
JWTs don't directly store session information locally. They facilitate SSO by carrying user information and authentication claims across applications.
Their stateless nature, compactness, and security features make them well-suited for various authentication and authorization scenarios.
Previous Solution, And Its Pain Points
Server Side Session Management
Server-side session management is a crucial aspect of web application development to maintain user state across multiple requests. Sessions enable the server to associate specific data with each user, allowing for personalized experiences. Here's an overview of server-side session management:
If is too much session request, the amount of session details increases cost of managing servers and Db to handle so many session detail
e.g. express-session
SAML (Security Assertion Markup Language):
XML-based standard for exchanging authentication and authorization information between applications.
Advantages:
More secure than cookies and basic authentication.
Supports single sign-on (SSO) across multiple applications.
Disadvantages:
Complex to implement and configure.
Requires additional infrastructure and support.
Not suitable for all types of applications.
Benefits of using JWTs:
JWTs are stateless, meaning the server doesn't need to store session information, making it scalable and suitable for distributed systems.
Secure: JWTs are signed, ensuring their authenticity and preventing unauthorized modifications to the payload.
Compact: JWTs are compact and efficient due to their JSON format, optimzed for web pages.
Self-contained: JWTs contain all the necessary information to validate their authenticity, making them ideal for stateless applications.
Versatile: JWTs can be used for various purposes beyond authentication, including session management, information exchange, and authorization.
Types of Authentication that can use JWT
JSON Web Tokens (JWT) are a type of token commonly used for authentication and authorization purposes. While JWT itself doesn't prescribe a specific authentication method, it is often used in conjunction with various authentication mechanisms. Two common types of authentication that can be associated with JWT are:
Session Authentication:
In a session-based authentication system, a user's authentication information is typically stored on the server side, and a unique session identifier (session token) is sent to the client after successful login.
The session token is then sent with each subsequent request to authenticate the user. This session token can be a JWT containing user information.
The server validates the session token and, if valid, grants access to the protected resources.
Token Authentication:
Token authentication involves issuing a token (often a JWT) to the client upon successful login.
The client includes this token in the Authorization header of each HTTP request to authenticate itself.
The server verifies the token's signature and checks its claims to authenticate the user.
Token authentication is stateless, meaning the server does not need to store session information, making it suitable for stateless APIs and microservices.
In summary, while both Session Authentication and Token Authentication can use JWTs as a means of representing and transmitting authentication information, they differ in their overall approach. Session Authentication involves server-side session management, while Token Authentication is stateless and relies on the client to present a valid token for each request. The choice between them often depends on the architecture and requirements of the application or system.
Components of a JWT:
Header: Contains metadata about the token, including the algorithm used to sign it and the type of token.
Payload: Contains the claims, which are statements about an entity (typically the user) and any other relevant information. These claims are not encrypted but signed, ensuring their integrity.
Signature: Ensures the token's authenticity and prevents tampering. It's created by signing the header and payload with a secret key.
REFERNCE