Authentication and Authorization Overview

In modern web applications, authentication and authorization are two fundamental

concepts used to control access to resources and ensure secure user interactions.
 Authentication: confirms the identity of a user or system.
 Authorization: determines what resources a user or system can access.
Together with distinct roles, authentication and authorization form the backbone of
secure web systems.
They help protect sensitive data, enforce user permissions, and ensure that only
trusted users can access or manipulate specific parts of a web application.

1. User Authentication
Cookies and sessions are commonly used in web applications to manage user
authentication.
o Server creates a session when the user logs in. The session ID is stored in a
cookie on the client side (browser).
o Sessions are considered stateful because the server stores session data for
each user, typically identified by a session ID saved in a browser cookie.

 Advantages:
o Simplifies user state management in stateful sessions. Page 9
o Easy to implement for small to medium-scale applications.
 Challenges:
o Scalability is a challenge for session-based authentication because, in
distributed systems, all servers must access the same session data. This
requires shared storage (like a database or cache) or sticky sessions, which
bind users to a specific server - both of which can limit scalability and
flexibility.

For example: Imagine a web application running on three servers behind a

load balancer:
 A user logs in, and their session data is stored on server A.
 On the next request, the load balancer may route the user to server B.
 Server B doesn't have the session data; thus, the user appears logged
out.

This example shows why session management becomes more complex in

scalable, multi-server environments.

Solutions include shared storage (e.g., Redis) for centralized session

access or sticky sessions, which route users to the same server for
consistency.
o Security risks: Cookies can be vulnerable to XSS (Cross-Site Scripting) or
CSRF (Cross-Site Request Forgery).

 Techniques to Mitigate Challenges 10 :

o Use Secure, HttpOnly, and SameSite cookie attributes.

1
 o Rotate (regenerate) session IDs upon authentication to prevent fixation
attacks which occur when an attacker forces a user to use a predetermined
session ID, then the attacker hijacks the session once the user logs-in.

2. JSON Web Tokens (JWT)

The JWT is a compact, URL-safe token used for secure information exchange
between parties. It consists of three parts which are base64-encoded and separated by
dots (.).

A token is a small piece of data used to represent the identity or permissions of a user
or system during interactions with a service. It acts as a substitute for more sensitive
credentials like passwords, allowing secure communication between parties. Tokens
are commonly used in authentication and authorization processes.

Principles:
A stateless authentication mechanism. Consists of three parts:
o Header: Specifies the token type and signing algorithm.
o Payload: Contains claims (e.g., user ID, roles, expiration).
o Signature: Ensures token integrity.

Header provides metadata about the token, specifying its type and the cryptographic
algorithm used for signing. Typically, it includes:

o alg: The signing algorithm, such as HS256 (HMAC-SHA256) or RS256 (RSA-

SHA256).
o typ: The token type, usually set to "JWT".

Example before encoding:

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

Payload contains the token's claims, which are pieces of information about the user or
session. Claims can be:
 Registered claims: Predefined keys like sub (subject), exp (expiration time),
or iat (issued at).
 Custom claims: Application-specific data like user roles, permissions, or
preferences.

This data is not encrypted by default but is base64-encoded. Anyone with access to
the token can read the payload.

Example (before encoding):

{
"sub": "1234567890",
"name": "John Doe",
"role": "admin",
"exp": 1699999999
}

2
Signature ensures the token's integrity and prevents tampering. It is created by:

1. Taking the base64-encoded Header and Payload.

2. Hashing them together with a secret key or private key using the algorithm
specified in the Header (e.g., HMAC or RSA).

If the token is altered, the Signature will no longer match, invalidating the token.

Example Signature creation:

HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secretKey
)

Key Characteristics:

 Compact: Typically small and lightweight, often encoded for efficient

transmission over networks.
 Secure: Designed to prevent unauthorized access or tampering (e.g., using
signatures or encryption).
 Time-Limited: Often includes expiration to minimize risk if stolen.
 Portable: Can be passed between systems or devices to facilitate access.

Advantages:
 Stateless: No need for server-side storage, making it scalable.
 Portable: Works across domains and systems.

Challenges:
 Revocation: Tokens can remain valid until they expire unless actively revoked.
 Size: Larger than session cookies, potentially increasing request overhead.

Example
A JSON Web Token (JWT) might look like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFt
ZSI6IkpvaG4gRG9lIiwiZXhwIjoxNjkyMzAwMDAwfQ.dBjftJeZ4CVP-
mB92K27uhbUJU1p1r_wW1gFWFOEjXk

It contains encoded data like user ID, roles, and expiration time, which can be
validated by the server to grant or deny access.

-------------------------------------------------------------------------------------------------------
-

3
3. OAuth 2.0 and Third-Party Authentication

OAuth 2.0 Principles

A framework for delegated access without sharing passwords.

Roles:
A. Resource Owner: User granting access.
B. Client: Application requesting access.
C. Authorization Server: Issues tokens.
D. Resource Server: Validates and uses tokens to grant access.

A. Resource Owner is the individual or entity that owns the data or resource being
accessed.

 Who? Usually the user granting permission to access their data.

 Role: Decides which application or system can access their resources.

Example:
A user wants to allow a third-party fitness app to access their step count data
from their wearable device.

B. Client is the application or service requesting access to the resource on behalf of

the Resource Owner.

 Who? The third-party application or service.

 Role: Sends an access request to the Authorization Server to get a token.

Example:
A fitness app (client) requests permission to access the user's step count data
from the wearable device’s API.

C. Authorization Server is responsible for authenticating the Resource Owner and

issuing tokens (e.g., access and refresh tokens).

 Who? A trusted system (often provided by the Resource Server or an identity

provider).
 Role:
o Verifies the Resource Owner's credentials.
o Issues a token that the Client can use to access resources.

Example:
The wearable device's platform provides an Authorization Server that
verifies the user and issues a token to the fitness app after the user grants
permission.

D. Resource Server hosts the resource (e.g., user data or APIs) and validates the
token presented by the Client to grant or deny access.

 Who? The server or API that holds the Resource Owner's data.

4
  Role:
o Verifies the validity of the token (e.g., checks its signature, expiration, and
permissions).
o Grants access if the token is valid and authorized.

Example:
The wearable device’s API (Resource Server) receives the token from the fitness app
and checks whether it’s valid. If valid, it grants access to the user's step count data.

How It Works (Example in Action)

1. User Grants Access:

o The fitness app redirects the user to the wearable device's Authorization
Server to log in and grant permission to access step count data.

2. Authorization Server Issues Token:

o After verifying the user, the Authorization Server issues an access token and
sends it to the fitness app.

3. Fitness App Makes Request with Token:

o The fitness app uses the token to request the user's step count data from the
wearable device’s Resource Server.

4. Resource Server Validates Token:

o The Resource Server checks the token (e.g., signature, expiration) and
ensures the app has the necessary permissions.

5. Access Granted:
o If the token is valid, the resource server returns the user's step count data to
the fitness app.

Simplified Roles and Interaction

Role Example in Fitness App Use Case

Resource Owner The user who owns the step count data.
Client The fitness app requesting access to the data.
Authorization The wearable platform's system issuing tokens.
Server
Resource Server The API of the wearable platform storing the data.

Risks:

o Dependency on third-party availability and policies.

o Privacy concerns with data sharing.
-------------------------------------------------------------------------------------------------------
-

5
4. Role-Based Access Control (RBAC)

Principles:

 Access is granted based on predefined roles (e.g., admin, user, editor).

 Roles are mapped to permissions for specific resources or actions.

Advantages:

 Centralized control: Easy to manage user permissions at scale.

 Reduces complexity compared to managing individual user permissions.

Implementation Steps:

1. Define roles and associated permissions.

2. Assign roles to users.
3. Apply permissions to resources based on roles.

Challenges:

 Role explosion: Too many roles can become unmanageable.

 Specificity: Roles may not always be sufficient for complex access needs.

Best Practices:
 Use hierarchical roles when possible (e.g., Admin > Manager > User).
 Regularly review roles and permissions to avoid unnecessary or excessive
access.
 Complement with Attribute-Based Access Control (ABAC) for fine-grained
policies.

Key Comparisons: Sessions vs. JWT vs. OAuth 2.0

Feature Sessions JWT OAuth 2.0

State Stateful (server Stateless
Delegated (via access tokens)
Management storage) (client-side)
Scalability Limited High High
Token theft, Token interception, scope
Security Risks XSS, CSRF
expiration misconfiguration
Use Cases Simple apps APIs, SPAs Third-party integrations

Emerging Trends
1. Passwordless Authentication:
o Methods: Biometric (fingerprint/face ID), magic links, OTPs.
o Eliminates traditional password vulnerabilities.

6
2. Zero Trust Security:
o Verifies identity and context at every access attempt, not just at login. This refer
to continuous authentication and context-aware access control to ensure that
every action or access request within a system is evaluated based on the user's
identity, behavior, and situational factors, rather than relying solely on a one-
time login event. Examples include; geolocation and IP monitoring, time-based
context, and device trust check.
o Purpose, assumes no trust anywhere; prioritizes comprehensive security.
o Resource Coverage: covers networks, applications, devices, and data.

3. Adaptive Authentication:
o Uses machine learning to adjust authentication requirements based on user
behavior or risk (e.g., unusual location).
o Purpose, balances security with user convenience.
o Resource coverage, primarily for access/authentication processes.

While adaptive authentication and zero trust security share overlapping principles,
they have distinct scopes and purposes. In practice, adaptive authentication can be a
part of a zero-trust security implementation, as it contributes to dynamically verifying
user identity and context. However, Zero Trust goes further by applying these
principles uniformly to all systems and resources, ensuring no implicit trust anywhere
within the environment.

Authentication and Authorization are foundational for application security. Choosing

the right approach depends on the system's complexity, scalability needs, and threat
model. While sessions and JWTs dominate internal systems, OAuth 2.0 enables
seamless integrations with third-party services.

7
Visual Guide on Session-Based Authentication

8
 user state management in stateful sessions 1

 When a user logs in, the state of their session (e.g., who they are, what
permissions they have, etc.) is stored centrally on the server.
 The client only holds a session ID, which acts as a reference to the session
data stored on the server.
 This simplifies user state management because:
1. Centralized Control: All session data resides on the server, making it
easy to update, validate, or terminate sessions without interacting with
the client.
2. Minimal Client Responsibility: The client only needs to send the
session ID with requests, reducing its role in maintaining session
details.
3. Flexibility for Changes: Any updates to the session (e.g., changing
user permissions) are immediately reflected because the session is
stored on the server.

Example:

If a user logs in to an e-commerce platform, the server might store:

 The user's ID.

 Their cart items.
 Their permissions (e.g., admin or regular user).

Whenever the user makes a request (e.g., adds an item to the cart), the server retrieves
and updates this data without requiring the client to manage it.

Why it’s Simplified Compared to Stateless Sessions

 In stateless sessions (e.g., with JSON WEB TOKEN JWT), the state is
embedded in the token on the client side. If a change is required (like revoking
a user’s permissions), the server must implement additional mechanisms (e.g.,
token blacklists) to ensure the system is aware of changes to user state.
 Stateful sessions avoid this complexity by directly updating the server-stored
session.

9
 1. Cookie attributes enhance security for cookies used in session
management 2

 Secure: Ensures cookies are only sent over HTTPS, preventing exposure over
unencrypted connections.

 HttpOnly: Restricts access to cookies from client-side scripts, mitigating risks

like XSS attacks. Ensuring sensitive data like session IDs cannot be stolen
through Cross-Site Scripting (XSS) attacks.

 SameSite: Controls when cookies are sent with cross-site requests, reducing
the risk of Cross-Site Request Forgery (CSRF) attacks.

10