Revisit Authentication Common Sense as a Web developer

[reboottime]

When we use various applications and websites, three essential security steps are continuously at play:

• Identity
• Authentication
• Authorization

Bellow is a diagram where these methods applied in a typical website architecture

Overview

This article revisits the authentication related common senses.

• Username and Password-Based Authentication
• JWT Tokens and Session Tokens
• OAuth 2.0 Authentication
• OpenID and Single Sign-On (SSO)

[reboottime]

Password Authentication

• How it works: In this method, users enter their unique username and password combination to gain access to protected resources. The entered credentials are checked against stored user information in the system, and if they match, the user is granted access.
• In the early of internet days, sharing usernames and passwords between services was common but discouraged due to potential misuse.

[reboottime]

HTTP Basic Authentication

The flow of HTTP Basic Authentication

• How client works on combining user name and password
  • format: username:password, for example, for username as user123 and its password as secretpassword, the combination is user123:secretpassword
  • client encodes the combination using Base64 encoding
  • the client includes the coded string into its request header called Authorization
• How the server works: The server reads the Authorization header and decodes the Base64-encoded string, and extracts the username and password for authentication string, then compare the username and password pair with the username and password stored in system.
• The Limitation
  • The username and password, encoded using Base64, can be easily decoded
  • Though most websites use TLS to encrypt data between the client and server, improving security. Yet the users' credentials may still be exposed to interception or man-in-the-middle attacks.

Session-Cookie Authentication

Session-cookie authentication addresses HTTP basic access authentication's inability to track user login status. A session ID is generated to track the user's status during their visit. This session ID is recorded both server-side and in the client’s cookie.

Bellow is the session cookie based interaction flow

JWT Token

JWT VS Session tokens

JSON Web Tokens (JWTs) and session tokens are both mechanisms used for authentication and authorization in web applications, but they have distinct characteristics and use cases. Here's a comparison of JWT tokens and session tokens:

JWT (JSON Web Token):

1. Self-Contained: JWTs are self-contained tokens that contain information (claims) in a structured format, typically in JSON. These claims can include user identity, access rights, and other relevant data.

2. Stateless: JWTs are inherently stateless, meaning the server does not need to maintain any session information. All the necessary information is within the token itself.

3. Decentralized: JWTs can be generated and signed by an authentication provider or Identity Provider (IdP) but can be verified by any party with the appropriate key. This decentralization can simplify authentication across different services.

4. Scalability: JWTs are suitable for distributed and microservices architectures, as they do not rely on a centralized session store. Each service can independently verify JWTs.

5. Expiration: JWTs can include an expiration time (exp claim) to control their validity. Once a JWT expires, it is no longer considered valid.

6. Use Cases: JWTs are commonly used in Single Sign-On (SSO), OAuth 2.0 authorization, and secure data transmission. They are well-suited for modern, stateless, and distributed application architectures.

Session Token:

1. Server-Side State: Session tokens typically rely on server-side state management. When a user logs in, a session token is created, and a session is established on the server to store user-specific data and maintain state.

2. Cookies or URL Parameters: Session tokens are often stored in cookies or passed as URL parameters to maintain user sessions across multiple requests. Cookies are the most common method for web applications.

3. Session Management: The server manages user sessions and session tokens, tracking user activity, session timeouts, and session cleanup.

4. Revocation: Session tokens can be revoked server-side, which allows administrators to log out users or terminate their sessions remotely.

5. Use Cases: Session tokens are commonly used in traditional server-side web applications, where maintaining server-side state is necessary. They are well-suited for monolithic architectures.

Considerations:

• JWTs are more suitable for stateless, distributed, and microservices-based applications, while session tokens are often used in traditional server-side applications.
• JWTs are versatile and can be used for various purposes, including authentication, authorization, and secure data transmission.
• Session tokens are typically easier to revoke, making them suitable for applications where session management and user control are critical.
• The choice between JWTs and session tokens depends on the architecture, use case, and requirements of your application.

In summary, JWTs and session tokens have different characteristics and are used in various contexts based on the specific needs of the application. The choice between them depends on factors such as the architecture, security requirements, and scalability of your application.

[reboottime]

OAuth 2.0 Standard Based Authentication

OAuth 2.0 is a protocol that allows you to grant your application permission to access your data on another application.

Let's use the Terrible Pun Joke case, to illustrate how OAuth 2.0 works.

There are three main parties involved in OAuth 2.0:

• The Terrible Pun Joke application
• A specific application user that use both google email client and Terrible Pun Joke application
• The Google Email application, which may act as both the resource owner and the authorization server.

Terrible Pun Jokes Application Perspective

From the perspective of the Terrible Pun Jokes application, there is a partnership between itself and the gmail client authorization server.

• The authorization server provides the client application with both the client secret and the client ID.

User's Journey Using Terrible Pun Jokes

Below is the user's journey when using the Terrible Pun Jokes application:

In above Okta tutorial about OAuth and OPEN ID connect, what has not been mentioned is that there exists some form of trust relationship between the identity provider and the resource server. Perhaps the resource server can directly contact the identity provider to validate the presented code from the client, or the resource server has a verification key to verify the code validity directly.

Bellow is the diagram describes the above statement

[reboottime]

OAuth and OPENID Connect (OIDC)

Recap on OAuth

OAuth is designed solely for authorization, allowing one application to grant access to data and features to another application. The OAuth flow provides the client with the necessary keys to access your data but does not reveal any information about the user's identity or characteristics.

OPENID Connect (OIDC)

OIDC is a layer built on top of OAuth 2.0, enhancing it with functionality related to user authentication and profile information. It enables the retrieval of information about the person who is logged in. For example, sign-in functionality using Google authentication.

Single Sign-On (SSO)

SSO, or "Single Sign-On," is an authentication process that allows users to access multiple applications or services using a single set of credentials, such as a username and password. Instead of needing separate login credentials for each application or service, SSO enables you to use the same login credentials for Google Mail and Google Docs, for instance.

OIDC vs OAuth

The ID token used in OIDC is similar to a JWT token, allowing you to decode encoded information or verify its integrity.

[reboottime]

References

• An Illustrated Guide to OAuth and OpenID Connect, By Okta
• bytebytego: Password, Session, Cookie, Token, JWT, SSO, OAuth - Authentication Explained - Part 1
• EP69: Explaining JSON Web Token (JWT) To a 10 Year Old Kid
• Authentication fundamentals: The basics | Azure Active Directory