JWT and Session-based authentication

·

5 min read

What is authentication?

Authentication is the process of verifying the identity of a user, device, or system. It ensures that the entity trying to access a resource or service is who or what it claims to be. Authentication is a crucial aspect of security in information systems, as it helps protect sensitive data and resources from unauthorized access.

What is JWT?

JWT, or JSON Web Token, is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity-protected with a Message Authentication Code (MAC) and/or encrypted.

In easy words, JWT stands for JSON Web Token. It is a way to securely transmit information between two parties — typically a client (like a web browser or mobile app) and a server. It is like a special pass or ticket used in web applications to prove that you are who you say you are.

How Does It Work?

  1. Log In: When you log into a website, the website gives you a token (like a digital badge).

  2. Token: This token contains information about you, such as your user ID or username.

  3. Sending the Token: Every time you make a request to the website (like visiting a new page), you send this token along with your request.

  4. Verification: The website checks the token to make sure it's valid. If it is, you get access to what you're trying to do.

What's Inside a JWT?

A JWT has three parts, separated by dots (.):

  1. Header: This tells what type of token it is and how it's signed.

  2. Payload: This contains important data about you (like your user ID).

  3. Signature: This is a security feature that ensures the token hasn’t been tampered with.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The first part is the Header, the second part is the Payload, and the third part is the Signature.

Key Points to Remember

  • Header: Usually looks like this:

      jsonCopy code{
        "alg": "HS256",
        "typ": "JWT"
      }
    

    This specifies that the token is using HMAC SHA256 for signing.

  • What is HMAC SHA 256?

    HMAC SHA256 is an algorithm. Specifically, it is a combination of two algorithms: HMAC and SHA256

  • Payload: Contains user information and claims, such as:

      jsonCopy code{
        "sub": "1234567890",
        "name": "John Doe",
        "iat": 1516239022
      }
    
    • sub (subject): Usually the user ID.

    • name: User’s name.

    • iat (issued at): Time when the token was issued.

  • Signature: Created by encoding the header and payload, and then signing it with a secret key. It ensures the token’s integrity.

Use Cases:

  1. Authentication: After a user logs in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token.

  2. Information Exchange: JWTs are a good way to securely transmit information between parties.

Security Considerations:

  1. Confidentiality: While the token is signed to verify its integrity, it is not encrypted by default. To ensure confidentiality, it should be encrypted using JWE.

  2. Expiration: Tokens should have an expiration time to mitigate risks associated with token leakage.

  3. Secure Storage: Tokens should be stored securely in the client-side (e.g., in cookies with HttpOnly and Secure flags set).

Overall, JWT is a powerful tool for web authentication and information exchange, balancing simplicity and security.

What is Season-based authentication?

Session-based authentication is a method where the server keeps track of the user's state by creating a session for them. Session-based authentication is like getting a ticket to use a service, and that ticket helps the service remember who you are.

In simple terms, session-based authentication is a way for websites to remember who you are by giving you a special ticket after you log in. This ticket is checked every time you do something on the site, so you don’t have to log in over and over again.

How It Works:

  1. Log In: You enter your username and password to log into a website.

  2. Server Checks: The website checks to make sure your username and password are correct.

  3. Create a Session: If everything is correct, the website gives you a session ID. Think of this like a ticket that says, "Hey, this is who I am!"

  4. Store the Session ID: The website stores this session ID on its server and also sends it to your browser, usually as a cookie.

  5. Making Requests: Whenever you click a link or do something on the website, your browser sends this session ID back to the website.

  6. Verify the Session ID: The website looks at the session ID, finds the stored session, and checks that it's still valid.

  7. Access Granted: If the session ID is valid, the website lets you do whatever you asked for.

Why Use Session-Based Authentication?

  • Keeps You Logged In: You don’t have to log in every time you go to a new page on the website.

  • Secure: The session information is stored on the server, so it’s harder for someone to steal your information.

Key Points:

  • Session ID: A unique identifier stored in your browser.

  • Cookies: Where the session ID is usually stored.

  • Server-Side Storage: The server keeps the session details, so it knows who you are.

  • Expiration: Sessions usually expire after a while, so you might have to log in again if you’re inactive for too long.

Choosing Between JWT and Session-Based Authentication

  • Use JWT if: You have a stateless application or microservices architecture, need scalability, are building a Single Page Application (SPA) or an API, and can ensure secure token handling.

  • Use Session-Based Authentication if: You have a traditional server-rendered web application, need built-in protection against some types of attacks like XSS (if implemented correctly), or require granular control over session lifetimes.

In practice, the choice often depends on the specific requirements of your application, your security considerations, and your architectural preferences. Some applications may even use a combination of both approaches for different parts of the system.