Skip to content

Authentication

Jump to bottom
FullstackCodingGuy edited this page Feb 7, 2025 · 7 revisions

Types of authentication

read image

[1.] 𝐀𝐏𝐈 𝐊𝐞𝐲𝐬 ◾ Simple, unique identifiers assigned to each client or service. ◾ Sent as a header or query parameter with each request. ◾ Best suited for internal services, less sensitive APIs, or for granting access to specific features. ◾ Easy to implement and manage. ◾ Not as secure as token-based methods. Keys can be easily leaked or stolen.

[2.] 𝐁𝐚𝐬𝐢𝐜 𝐀𝐮𝐭𝐡𝐞𝐧𝐭𝐢𝐜𝐚𝐭𝐢𝐨𝐧 ◾ Username and password are sent in the Authorization header as base64 encoded string. ◾ Simple to implement but requires HTTPS to be secure. ◾ Suitable for simple scenarios with low-security requirements. ◾ Widely supported and easy to understand. ◾ Vulnerable to man-in-the-middle attacks if not used with HTTPS. ◾ Passwords are sent in cleartext (even when encoded).

[3.] 𝐉𝐒𝐎𝐍 𝐖𝐞𝐛 𝐓𝐨𝐤𝐞𝐧𝐬 (𝐉𝐖𝐓) ◾ Self-contained tokens that carry user information and claims in a JSON payload. ◾ Issued by an authentication server after successful login, then sent by the client in the Authorization header. ◾ Widely used for stateless authentication in microservices, single sign-on (SSO) and authorization. ◾ Stateless, secure, compact and can contain additional claims. ◾ Requires proper key management for signing and verification.

[4.] 𝐎𝐀𝐮𝐭𝐡 2.0 ◾ An authorization framework allowing third-party applications to obtain limited access to resources on behalf of the resource owner (user) without sharing credentials. ◾ Uses various grant types (authorization code, implicit, client credentials, etc.) to obtain access tokens and refresh tokens. ◾ Widely used for user authorization and delegated access to APIs. ◾ Provides a standardized way to secure access to resources without sharing credentials. ◾ Can be complex to implement and requires careful consideration of security vulnerabilities.

[5.] 𝐎𝐩𝐞𝐧𝐈𝐃 𝐂𝐨𝐧𝐧𝐞𝐜𝐭 (𝐎𝐈𝐃𝐂) ◾ An identity layer on top of OAuth 2.0 that provides user authentication and profile information. ◾ Uses an ID token along with the access token to provide user identity information. ◾ Used for authentication in conjunction with OAuth 2.0 for authorization. ◾ Simplifies authentication by providing a standardized way to obtain user information. ◾ Requires integration with an OIDC provider (e.g., Google, Okta).

[6.] 𝐌𝐮𝐭𝐮𝐚𝐥 𝐓𝐋𝐒 (𝐦𝐓𝐋𝐒) ◾ Both client and server authenticate each other using X.509 certificates. ◾ Requires a certificate authority (CA) to issue and manage certificates. ◾ Best suited for securing communication between internal services or highly sensitive APIs. ◾ Strong security due to mutual authentication and encryption. ◾ More complex to set up and manage compared to other mechanisms.

Session based Vs JWT based

Think of session-based authentication like a boarding pass ID at an airport. The system keeps the details about your session in a secure store, and you’re given a session ID to use.

How It Works:

  1. The user logs in, and their credentials are validated by the server.
  2. The server creates a session with all user details and stores it in a session store (database or memory).
  3. A session ID is sent back to the client as a cookie.
  4. On every subsequent request, the browser sends the session ID cookie to the server.
  5. The server checks the session store for the ID to verify the user.

Pros:

  • Easy to invalidate sessions (just remove them from the store).
  • Familiar and simple for server-side apps.

Cons:

  • Not ideal for distributed systems (requires shared session storage).
  • Can become a bottleneck as the user base grows.

Imagine JWTs as your boarding pass with all flight details printed on it, but encrypted and signed. The server doesn’t need to store anything because the token itself holds all necessary data.

How It Works:

  1. The user logs in, and their credentials are validated by the server.
  2. The server generates a JWT containing user data (e.g., user ID, roles) and signs it with a secret key.
  3. The JWT is sent back to the client as a cookie or header.
  4. On subsequent requests, the browser sends the JWT.
  5. The server verifies the JWT using the secret key and extracts user data.

Pros:

  • Stateless: No server-side storage required.
  • Ideal for distributed systems and scaling.
  • Works well with microservices and client-side rendering.

Cons:

  • Revoking JWTs is difficult (you can’t just delete them).
  • Tokens can become stale if user permissions or roles change.
  • Larger payloads can slow down requests.

Session vs. JWTs: When to Use What?

Session-Based Authentication:

  • Centralized server architecture.
  • Easier to manage for small to medium-scale projects.
  • Applications where sessions need to be invalidated quickly (e.g., financial apps).

JWT-Based Authentication:

  • Distributed systems or microservices architecture.
  • When scalability is a priority.
  • Applications with APIs accessed by multiple clients (e.g., mobile and web apps).
Clone this wiki locally