Menu

Showing posts with label Azure Entra ID. Show all posts
Showing posts with label Azure Entra ID. Show all posts

15 Jun 2026

🧩 SSO , MFA (Multi-Factor Authentication) & Microsoft Entra ID Authentication Explained - Part 8

SSO (Single Sign-On), MFA (Multi-Factor Authentication) & Microsoft Entra ID Authentication Explained
  • Welcome to Part 8 of the Authentication & Identity Security series.
  • This article explains SSO (Single Sign-On), MFA (Multi-Factor Authentication), and Microsoft Entra ID authentication.
  • Designed for Middleware, DevOps, Cloud, Security, and Application Support Engineers.
  • Includes enterprise examples using Microsoft Entra ID, SSO (Single Sign-On), MFA (Multi-Factor Authentication), Conditional Access, OIDC (OpenID Connect), SAML (Security Assertion Markup Language), and application integration.


Introduction

In Part 7, we learned about OAuth2, OpenID Connect (OIDC), and SAML. These protocols are commonly used by enterprise identity platforms to provide secure application login and API access.

In this article, we will understand three important enterprise identity concepts: SSO (Single Sign-On), MFA (Multi-Factor Authentication), and Microsoft Entra ID (formerly Azure Active Directory).

Simple Understanding:
SSO (Single Sign-On) allows users to login once and access multiple applications. MFA (Multi-Factor Authentication) adds an extra verification step. Microsoft Entra ID is Microsoft's cloud identity platform that provides SSO, MFA, Conditional Access, and identity governance.

Common Terms Used in This Article

Abbreviation Full Form / Meaning
SSOSingle Sign-On
MFAMulti-Factor Authentication
Microsoft Entra IDFormerly Azure Active Directory
IAMIdentity and Access Management
OIDCOpenID Connect
OAuth2Open Authorization 2.0
SAMLSecurity Assertion Markup Language
JWTJSON Web Token
ADFSActive Directory Federation Services
APIApplication Programming Interface

What is SSO (Single Sign-On)?

SSO stands for Single Sign-On.

SSO allows users to authenticate once and access multiple applications without entering credentials again for every application.

SSO Flow

User
  │
  ▼
Identity Provider
(Azure Entra ID / Okta / ADFS)
  │
  ▼
Authentication Successful
  │
  ▼
Access Multiple Applications

Enterprise Example

User logs in once to Microsoft Entra ID
        │
        ├── Microsoft 365
        ├── ServiceNow
        ├── HR Portal
        ├── Azure Portal
        └── Internal Web Application

Benefits of SSO

  • Users remember fewer passwords.
  • Centralized authentication management.
  • Improved user experience.
  • Reduced password reset tickets.
  • Better audit and access control.

What is MFA (Multi-Factor Authentication)?

MFA stands for Multi-Factor Authentication.

MFA requires users to verify their identity using more than one factor.

Common MFA Factors

Factor Example
Something you know Password or PIN
Something you have Mobile phone, authenticator app, hardware token
Something you are Biometric verification

MFA Flow

User enters password
      │
      ▼
Password verified
      │
      ▼
MFA challenge
      │
      ▼
Authenticator App / SMS / Push Approval
      │
      ▼
Access granted
Security View:
MFA protects accounts even if the user's password is compromised.

What is Microsoft Entra ID (formerly Azure Active Directory)?

Azure Entra ID, now known as Microsoft Entra ID, is Microsoft's cloud-based identity and access management platform.

It helps organizations manage users, groups, applications, authentication, SSO, MFA, Conditional Access, and identity security.

Microsoft Entra ID Provides

  • User and group management
  • Single Sign-On
  • Multi-Factor Authentication
  • Conditional Access
  • Application registrations
  • Enterprise application integration
  • OAuth2 (Open Authorization 2.0), OIDC (OpenID Connect), and SAML (Security Assertion Markup Language) support
  • Access reviews and identity governance

Enterprise Authentication Flow

User Browser
      │
      ▼
Enterprise Application
      │
      ▼
Microsoft Entra ID
      │
      ▼
Password Authentication
      │
      ▼
MFA / Conditional Access
      │
      ▼
Token or SAML Assertion Issued
      │
      ▼
Application Access Granted

In this flow, the application does not directly validate the user's password. Instead, it redirects the user to Microsoft Entra ID, which performs authentication and returns a token or SAML assertion.


SSO Protocols: OIDC (OpenID Connect) and SAML (Security Assertion Markup Language)

SSO can be implemented using different protocols depending on the application type.

Application Type Recommended Protocol
Modern web application OIDC
REST API access OAuth2
Legacy enterprise web application SAML
Mobile application OIDC with PKCE
Partner federation SAML or OIDC

Conditional Access

Conditional Access is a policy-based security feature in Microsoft Entra ID. It evaluates conditions before allowing access.

Common Conditions

  • User or group
  • Application being accessed
  • Device compliance
  • Location or country
  • Sign-in risk
  • Client application type

Common Controls

  • Require MFA
  • Block access
  • Require compliant device
  • Require password change
  • Grant access only from trusted locations
User Login
   │
   ▼
Conditional Access Policy Check
   │
   ├── Trusted Device? 
   ├── Trusted Location?
   ├── MFA Required?
   │
   ▼
Access Allowed or Blocked
Example:
Require MFA when users access Azure Portal from outside the corporate network.

How to Setup SSO (Single Sign-On) and MFA (Multi-Factor Authentication) in Microsoft Entra ID

Example 1: Setup SSO for an Enterprise Application

  1. Login to Microsoft Entra Admin Center.
  2. Go to Enterprise applications.
  3. Select or create the application.
  4. Open Single sign-on.
  5. Choose protocol: SAML or OIDC depending on application support.
  6. Configure Identifier, Reply URL, Redirect URI, or metadata.
  7. Configure user attributes and claims.
  8. Assign users or groups to the application.
  9. Test SSO login.

Example 2: Enable MFA

  1. Go to Microsoft Entra Admin Center.
  2. Open Protection or Conditional Access.
  3. Create a new Conditional Access policy.
  4. Select target users or groups.
  5. Select target application.
  6. Under Grant controls, choose Require multifactor authentication.
  7. Enable policy in report-only mode first.
  8. Review sign-in logs and then enforce the policy.

Example Conditional Access Policy

Policy Name  : Require MFA for Azure Portal
Users        : Cloud Admins
Application  : Microsoft Azure Management
Condition    : Any location
Control      : Require MFA
Status       : Enabled
Production Tip:
Always test Conditional Access policies with pilot users before enabling them for all users. Keep at least one emergency break-glass account excluded from restrictive policies.

Middleware Application Integration Example

Modern OIDC (OpenID Connect) Application

User Browser
      │
      ▼
NGINX / Load Balancer
      │
      ▼
Application
      │
      ▼
Microsoft Entra ID
      │
      ▼
ID Token + Access Token
      │
      ▼
Application Session Created

Legacy SAML (Security Assertion Markup Language) Application

User Browser
      │
      ▼
IBM HTTP Server / Reverse Proxy
      │
      ▼
Legacy Enterprise Application
      │
      ▼
Microsoft Entra ID / ADFS
      │
      ▼
SAML Assertion
      │
      ▼
Application Access Granted

API (Application Programming Interface) Access with OAuth2 (Open Authorization 2.0)

Client Application
        │
        ▼
Microsoft Entra ID
        │
        ▼
Access Token
        │
        ▼
Azure API Management / API Gateway
        │
        ▼
Backend API

Middleware and DevOps teams often support these integrations by configuring reverse proxies, SSL certificates, redirect URLs, headers, application endpoints, load balancers, and logs.


SSO (Single Sign-On) vs MFA (Multi-Factor Authentication) vs Microsoft Entra ID

Concept Meaning Purpose
SSO (Single Sign-On) Login once and access multiple applications Login once and access multiple applications
MFA (Multi-Factor Authentication) Add extra verification during login Add extra verification during login
Microsoft Entra ID Cloud identity platform Provides SSO, MFA, Conditional Access, app integration
Conditional Access Policy-based access control Allow, block, or require MFA based on conditions

Common Issues

Issue Possible Cause
SSO login loop Cookie, redirect URI, or session issue
Invalid redirect URI Application URL mismatch in Entra ID
MFA prompt not appearing Conditional Access policy not applied
User cannot access application User not assigned to enterprise application
SAML assertion failed Certificate, metadata, NameID, or claim mismatch
Token validation failed Invalid issuer, audience, expiry, or signing key
Access blocked unexpectedly Conditional Access location/device/risk condition

Best Practices

  • Use SSO for enterprise applications to centralize authentication.
  • Enable MFA for privileged users and high-risk applications.
  • Use Conditional Access instead of enabling MFA blindly for everyone.
  • Use OIDC for modern applications and SAML for legacy applications when required.
  • Assign applications to groups instead of individual users.
  • Monitor sign-in logs and audit logs regularly.
  • Keep redirect URIs and reply URLs strict.
  • Rotate SAML certificates and application secrets before expiry.
  • Maintain break-glass emergency accounts.
  • Document application integration details for support teams.

Key Takeaways

  • SSO (Single Sign-On) allows users to login once and access multiple applications.
  • MFA (Multi-Factor Authentication) adds an extra verification layer beyond passwords.
  • Microsoft Entra ID was formerly known as Azure Active Directory.
  • SSO improves user experience and centralizes login.
  • MFA improves security by adding an extra verification step.
  • Conditional Access controls when and how access is granted.
  • Microsoft Entra ID supports OAuth2, OIDC, and SAML integrations.
  • Middleware teams should understand redirect URI, certificates, claims, headers, and logs for troubleshooting.

What’s Next?

Next Article:
Part 9 – WebSphere LTPA, Sticky Sessions & Session Replication

In the next article, we will understand WebSphere LTPA, sticky sessions, session affinity, and session replication in traditional enterprise middleware environments.


Series: Authentication & Identity Security for Middleware, DevOps & Cloud Engineers
Author: Pradeep V
Blog: MiddlewareBox.com


πŸ”‘ OAuth2, OpenID Connect (OIDC) & SAML Explained - Part 7

OAuth2, OpenID Connect (OIDC) & SAML Explained
  • Welcome to Part 7 of the Authentication & Identity Security series.
  • This article explains OAuth2, OpenID Connect (OIDC), and SAML in simple enterprise language.
  • Designed for Middleware, DevOps, Cloud, Security, and Application Support Engineers.
  • Includes examples using Azure Entra ID, SSO, APIs, JWT tokens, enterprise applications, and identity federation.


Introduction

In Part 6, we learned about API Authentication and API Gateway Security. In this article, we will understand three very important identity and access technologies: OAuth2, OpenID Connect (OIDC), and SAML.

These technologies are widely used in modern enterprises for API access, Single Sign-On (SSO), cloud applications, Microsoft Entra ID integrations, and identity federation.

Simple Understanding:
OAuth2 is mainly for authorization. OIDC is for authentication on top of OAuth2. SAML is commonly used for enterprise Single Sign-On using XML-based assertions.

What is OAuth2?

OAuth2 stands for Open Authorization 2.0.

OAuth2 is an authorization framework that allows an application to access protected resources on behalf of a user without sharing the user's password with that application.

OAuth2 Simple Flow

User
  │
  ▼
Client Application
  │
  ▼
Authorization Server
  │
  ▼
Access Token Issued
  │
  ▼
Protected API

OAuth2 answers this question:

What can this application access?

OAuth2 Example

Client Application
        │
        ▼
Azure Entra ID
        │
        ▼
Access Token
        │
        ▼
API Gateway / Backend API

OAuth2 is heavily used for API access, mobile applications, web applications, machine-to-machine integrations, and cloud services.


What is OpenID Connect (OIDC)?

OIDC stands for OpenID Connect.

OIDC is an identity layer built on top of OAuth2. It is used to authenticate users and provide identity information to applications.

OAuth2 provides access tokens. OIDC adds an ID Token, which tells the application who the user is.

OIDC Simple Flow

User
  │
  ▼
Application
  │
  ▼
Identity Provider
  │
  ▼
ID Token + Access Token
  │
  ▼
Application Login Successful

OIDC answers this question:

Who is the user?

OIDC Example

User logs in to application
        │
        ▼
Azure Entra ID authenticates user
        │
        ▼
Application receives ID Token
        │
        ▼
Application knows user's identity
Important:
OIDC is commonly used for modern web application login and Single Sign-On with Azure Entra ID, Okta, Keycloak, and other identity providers.

What is SAML?

SAML stands for Security Assertion Markup Language.

SAML is an XML-based standard used for exchanging authentication and authorization data between an Identity Provider and a Service Provider.

SAML Simple Flow

User
  │
  ▼
Service Provider Application
  │
  ▼
Identity Provider Login
  │
  ▼
SAML Assertion Issued
  │
  ▼
Application Access Granted

SAML is commonly used for enterprise SSO with older and traditional enterprise applications.

SAML Example

User opens HR portal
        │
        ▼
Redirect to Azure Entra ID / ADFS
        │
        ▼
User authenticates
        │
        ▼
SAML Assertion sent to HR portal
        │
        ▼
User login successful

OAuth2 vs OIDC

OAuth2 and OIDC are closely related, but they are not the same.

OAuth2 OIDC
Authorization framework Authentication layer on top of OAuth2
Used to access APIs Used to log in users
Issues Access Token Issues ID Token and Access Token
Answers: What can the app access? Answers: Who is the user?
Common in API security Common in SSO login
Memory Shortcut:
OAuth2 = Access to APIs
OIDC = Login and user identity

OIDC vs SAML

Point OIDC SAML
Format JSON / JWT XML
Modern Usage Modern web apps, APIs, mobile apps Enterprise SSO, older web apps
Token / Assertion ID Token SAML Assertion
Protocol Base OAuth2 SAML standard
Cloud Native Friendly High Medium
Common Providers Azure Entra ID, Okta, Keycloak Azure Entra ID, ADFS, PingFederate

Azure Entra ID Example

Microsoft Entra ID supports OAuth2, OIDC, and SAML for application authentication and authorization.

Modern Application Using OIDC

User
  │
  ▼
Web Application
  │
  ▼
Microsoft Entra ID
  │
  ▼
ID Token + Access Token
  │
  ▼
Application Login Successful

API Access Using OAuth2

Client Application
        │
        ▼
Microsoft Entra ID
        │
        ▼
OAuth2 Access Token
        │
        ▼
Azure API Management
        │
        ▼
Backend API

Enterprise SSO Using SAML

User
  │
  ▼
Legacy Enterprise Application
  │
  ▼
Microsoft Entra ID / ADFS
  │
  ▼
SAML Assertion
  │
  ▼
Application Access Granted

Enterprise SSO Architecture

User Browser
      │
      ▼
Enterprise Application
      │
      ▼
Identity Provider
(Azure Entra ID / Okta / ADFS)
      │
      ▼
Authentication + MFA
      │
      ▼
Token / Assertion
      │
      ▼
Application Access

In this architecture, applications do not manage user passwords directly. Authentication is delegated to a centralized identity provider.

Benefits

  • Centralized identity management
  • Single Sign-On
  • Multi-Factor Authentication
  • Conditional Access
  • Better audit and compliance
  • Reduced password handling by applications

Access Token, ID Token & SAML Assertion

Item Used By Purpose
Access Token OAuth2 Access protected APIs
ID Token OIDC Prove user identity to application
SAML Assertion SAML Provide authentication result to service provider

Example Access Token Usage

GET /api/customer
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Example ID Token Purpose

Application receives ID Token
Application reads user identity claims
User login is established

Example SAML Assertion Purpose

Identity Provider sends SAML Assertion
Service Provider validates assertion
User gets access to application

Where OAuth2, OIDC and SAML are Used

Use Case Recommended Protocol
REST API access OAuth2
Modern web application login OIDC
Mobile app login OIDC
Single Page Application OIDC with Authorization Code + PKCE
Legacy enterprise SSO SAML
Microsoft Graph API access OAuth2
Partner enterprise federation SAML or OIDC

OAuth2 vs OIDC vs SAML Comparison

Feature OAuth2 OIDC SAML
Full Form Open Authorization 2.0 OpenID Connect Security Assertion Markup Language
Main Purpose Authorization Authentication Enterprise SSO
Common Format Token JWT / JSON XML
Common Output Access Token ID Token SAML Assertion
Best For APIs Modern login Enterprise web SSO
Modern Cloud Usage High High Medium

How to Setup OAuth2, OIDC and SAML - Practical Example

Below is a high-level enterprise setup example using Microsoft Entra ID as the Identity Provider. The same concept applies to Okta, Keycloak, PingFederate, and other identity platforms.

Important:
Exact screens may differ based on the identity provider, but the core setup flow remains almost the same: register application, configure redirect URI, assign users, generate client details, and configure the application.

Example 1: Setup OIDC Login for a Web Application

Use OIDC when your application needs user login and Single Sign-On.

User
  │
  ▼
Web Application
  │
  ▼
Microsoft Entra ID
  │
  ▼
ID Token + Access Token
  │
  ▼
Application Login Successful

High-Level Setup Steps

  1. Login to Microsoft Entra Admin Center.
  2. Go to App registrations.
  3. Create a new application registration.
  4. Configure the application redirect URI.
  5. Create a client secret if the application is confidential.
  6. Configure required API permissions.
  7. Assign users or groups if required.
  8. Configure the application with Client ID, Tenant ID, Client Secret, and Redirect URI.

Example OIDC Configuration

Tenant ID     : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Client ID     : yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
Redirect URI  : https://app.company.com/signin-oidc
Authority URL : https://login.microsoftonline.com/{tenant-id}
Scope         : openid profile email

Common OIDC Use Cases

  • Enterprise web application login
  • Single Sign-On for internal portals
  • Cloud-native application authentication
  • Modern replacement for application-managed passwords

Example 2: Setup OAuth2 for API Access

Use OAuth2 when an application needs to access a protected API using an access token.

Client Application
        │
        ▼
Microsoft Entra ID
        │
        ▼
OAuth2 Access Token
        │
        ▼
API Gateway / Backend API

High-Level Setup Steps

  1. Register the backend API in Microsoft Entra ID.
  2. Expose an API scope such as api.read or api.write.
  3. Register the client application.
  4. Grant the client application permission to call the API.
  5. Use OAuth2 flow to request an access token.
  6. Send the access token to the API using the Authorization header.
  7. Validate token issuer, audience, expiry, and signature at API Gateway or backend API.

Example API Request

GET /api/customer HTTP/1.1
Host: api.company.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Example Token Validation Points

  • Issuer should match Microsoft Entra ID tenant.
  • Audience should match the API Application ID URI.
  • Token should not be expired.
  • Signature should be valid.
  • Required scope or role should be present.

Example 3: Setup SAML SSO for an Enterprise Application

Use SAML when integrating legacy enterprise applications that support SAML-based Single Sign-On.

User
  │
  ▼
Enterprise Application
  │
  ▼
Microsoft Entra ID / ADFS
  │
  ▼
SAML Assertion
  │
  ▼
Application Login Successful

High-Level Setup Steps

  1. Create or select an Enterprise Application in Microsoft Entra ID.
  2. Select Single sign-on and choose SAML.
  3. Configure Identifier / Entity ID.
  4. Configure Reply URL / ACS URL.
  5. Configure Sign-on URL if required.
  6. Download Federation Metadata XML or certificate.
  7. Upload metadata or certificate to the Service Provider application.
  8. Map claims such as username, email, name, and groups.
  9. Assign users or groups to the application.
  10. Test SSO login.

Example SAML Configuration

Identifier / Entity ID : https://app.company.com/saml/metadata
Reply URL / ACS URL    : https://app.company.com/saml/acs
Sign-on URL            : https://app.company.com
NameID Format          : emailAddress

Common SAML Use Cases

  • Legacy enterprise web applications
  • HR portals
  • Vendor applications
  • Enterprise SaaS applications
  • Applications integrated with ADFS or Entra ID

Quick Setup Comparison

Requirement Recommended Setup Example
User login for modern web app OIDC App receives ID Token
API access OAuth2 API receives Access Token
Legacy enterprise SSO SAML Application receives SAML Assertion
Mobile app login OIDC with PKCE Mobile app receives tokens securely
System-to-system API OAuth2 Client Credentials Service principal gets access token
Middleware Engineer Tip:
For troubleshooting, always check Redirect URI, Reply URL, Entity ID, Audience, Issuer, Certificate, Token Expiry, and Claim Mapping first. Most OAuth2, OIDC, and SAML issues are caused by mismatch in these values.

Common Issues

Issue Possible Cause
Invalid redirect URI Application redirect URL mismatch in identity provider
Invalid audience Token issued for different API or application
Invalid issuer Wrong identity provider or tenant configured
SAML assertion validation failed Certificate, timestamp, or metadata mismatch
OIDC login loop Cookie, redirect URI, or session issue
Access denied after login Authentication successful but authorization missing

Best Practices

  • Use OIDC for modern application login.
  • Use OAuth2 for API access and delegated authorization.
  • Use SAML for legacy enterprise SSO where required.
  • Always validate issuer, audience, expiry, and signature.
  • Use HTTPS for all authentication and token flows.
  • Use Authorization Code Flow with PKCE for modern applications.
  • Do not store secrets in frontend applications.
  • Rotate certificates and signing keys regularly.
  • Enable MFA and Conditional Access in enterprise environments.
  • Keep redirect URIs strict and controlled.

Key Takeaways

  • OAuth2 stands for Open Authorization 2.0.
  • OAuth2 is mainly used for authorization and API access.
  • OIDC stands for OpenID Connect.
  • OIDC is used for authentication and user login.
  • SAML stands for Security Assertion Markup Language.
  • SAML is commonly used for enterprise SSO.
  • Azure Entra ID supports OAuth2, OIDC, and SAML.
  • OAuth2 issues access tokens, OIDC issues ID tokens, and SAML uses assertions.

What’s Next?

Next Article:
Part 8 – SSO, MFA & Azure Entra ID Authentication

In the next article, we will understand Single Sign-On, Multi-Factor Authentication, and how Azure Entra ID helps secure enterprise applications.


Series: Authentication & Identity Security for Middleware, DevOps & Cloud Engineers
Author: Pradeep V
Blog: MiddlewareBox.com


⚖️ JWT vs Session vs Cookies Explained - Part 5

JWT vs Session vs Cookies Explained
  • Welcome to Part 5 of the Authentication & Identity Security series.
  • This article explains the difference between JWT, Sessions and Cookies.
  • Designed for Middleware, DevOps, Cloud, API, and Application Support Engineers.
  • Includes enterprise examples using WebSphere, JBoss, Tomcat, Docker, Azure Entra ID, APIs, and Load Balancers.


Introduction

In previous parts, we learned about sessions, cookies, JSESSIONID, stateful applications, stateless applications, and JWT-based authentication.

Now it is important to clearly understand the difference between Cookies, Sessions and JWT. Many engineers confuse these terms and use them interchangeably, but they are different concepts.

Simple Understanding:
A cookie is stored in the browser. A session is stored on the server. A JWT is a signed token usually used for stateless authentication.

A cookie is a small piece of data stored in the user's browser. The server sends a cookie to the browser, and the browser sends it back with future requests.

Cookies are commonly used to store identifiers, preferences, tracking values, and session IDs.

Example Cookie

Set-Cookie: JSESSIONID=ABC123XYZ789; Path=/app; Secure; HttpOnly

Browser Sends Cookie Back

GET /app/dashboard HTTP/1.1
Host: www.company.com
Cookie: JSESSIONID=ABC123XYZ789
Important:
A cookie is only a storage mechanism in the browser. It is not the same as a session.

What is a Session?

A session is server-side storage used to maintain user information after login.

In Java enterprise applications, the session is commonly identified using JSESSIONID.

Session Data Example

Session ID: ABC123XYZ789

Stored on Server:
- userId = pradeep
- role = admin
- loginTime = 10:30 AM
- applicationAccess = policy-portal

The browser does not usually store this full session data. The browser only stores the JSESSIONID cookie. The actual session data remains inside the application server memory or external session store.

Common Platforms

  • IBM WebSphere Application Server
  • WebSphere Liberty
  • Apache Tomcat
  • JBoss EAP
  • WildFly

What is JWT?

JWT stands for JSON Web Token. It is a signed token that contains claims about the user or application.

JWT is commonly used in APIs, microservices, mobile applications, Docker-based applications, and cloud-native systems.

JWT Example

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiJwcmFkZWVwIiwicm9sZSI6ImFkbWluIn0.
signature

JWT Payload Example

{
  "sub": "pradeep",
  "role": "admin",
  "iss": "https://login.company.com",
  "aud": "api.company.com",
  "exp": 1789459200
}
Important:
JWT payload is encoded, not encrypted by default. Do not store passwords, secrets, or sensitive data inside JWT.

Cookie, Session and JWT Flow

Session + Cookie Flow

User Login
   │
Application Server Authenticates User
   │
Server Creates Session
   │
Server Generates JSESSIONID
   │
Browser Stores JSESSIONID Cookie
   │
Browser Sends Cookie With Every Request
   │
Server Finds Session Using JSESSIONID

JWT Flow

User Login
   │
Authentication Server Validates User
   │
JWT Generated
   │
Client Stores JWT
   │
Client Sends JWT With API Request
   │
API Validates JWT Signature and Expiry
   │
Access Granted

JWT vs Session vs Cookies Comparison

Feature Cookie Session JWT
Basic Meaning Browser storage mechanism Server-side user state Signed authentication token
Stored In Browser Application Server / External Store Client side
Common Example JSESSIONID cookie User session in JVM heap Bearer token
Stateful / Stateless Storage only Stateful Stateless
Server Memory Required No Yes, unless externalized No session memory required
Scaling Easy Requires sticky session or replication Easier horizontal scaling
Best For Session ID, preferences Traditional web applications APIs, mobile apps, microservices
Security Risk Cookie theft Session hijacking Token theft

Enterprise Middleware Example

Traditional WebSphere / JBoss / Tomcat Application

Browser
   │
JSESSIONID Cookie
   │
IBM HTTP Server / NGINX
   │
WebSphere / JBoss / Tomcat
   │
Session Stored in JVM Memory

This architecture is common in enterprise web applications. The application server stores session data and the browser stores only the JSESSIONID.

Common Requirements

  • Session timeout configuration
  • Sticky session at load balancer
  • Session replication in cluster
  • Secure and HttpOnly cookie flags
  • Logout session invalidation

Docker and Cloud Perspective

Docker does not automatically make an application stateless. If the application running inside the container stores sessions in JVM memory, it is still stateful.

Stateful Docker Application

Browser
   │
JSESSIONID Cookie
   │
Docker Container
   │
Tomcat / JBoss / WebSphere Liberty
   │
Session Stored in Container JVM Memory

If the container restarts or is replaced, in-memory sessions may be lost.

Better Cloud-Native Options

  • Use JWT-based stateless authentication
  • Use Redis as external session store
  • Use database-backed session persistence
  • Use short-lived tokens with refresh tokens
  • Use API Gateway for centralized token validation

Azure Entra ID Perspective

Azure Entra ID commonly issues tokens for modern enterprise applications and APIs.

User
 │
Application
 │
Azure Entra ID Login
 │
Access Token / ID Token
 │
Application or API Access

In this model, Azure Entra ID handles authentication and issues tokens. Applications validate the token before granting access.

Enterprise Use Case:
Azure Entra ID + OAuth2/OIDC + JWT is commonly used for SSO, API authentication, Azure applications, and cloud-native platforms.

Which One Should You Use?

Application Type Recommended Approach
Traditional WebSphere / JBoss / Tomcat web app Session + Cookie
REST API JWT / OAuth2 Access Token
Docker-based application JWT or Redis-backed session
Single Page Application OIDC with secure token handling
Enterprise SSO Azure Entra ID / SAML / OIDC
Legacy Java application Session-based authentication

Common Misconceptions

Misconception 1: Cookie and Session are Same

This is incorrect. A cookie is stored in the browser. A session is stored on the server.

Misconception 2: JWT Always Replaces Session

JWT is useful for APIs and stateless architectures, but traditional web applications may still use sessions effectively.

Misconception 3: JWT is Always More Secure

JWT security depends on implementation. Poor token storage, long expiry, missing validation, or weak signing keys can create serious risks.

Misconception 4: Docker Makes Applications Stateless

Docker only packages and runs applications. If the application stores sessions in memory, it remains stateful.


Security Best Practices

Cookie Best Practices

  • Use Secure flag for HTTPS-only transmission.
  • Use HttpOnly flag to reduce JavaScript access.
  • Use SameSite attribute to reduce CSRF risk.
  • Set proper cookie path and domain.

Session Best Practices

  • Configure proper session timeout.
  • Invalidate session after logout.
  • Regenerate session ID after login.
  • Use session replication or external session store for HA.
  • Avoid storing unnecessary large objects in session.

JWT Best Practices

  • Use HTTPS for all token communication.
  • Keep access tokens short-lived.
  • Validate signature, expiry, issuer, and audience.
  • Never store passwords or secrets in JWT payload.
  • Use refresh tokens carefully.
  • Rotate signing keys periodically.

Common Production Issues

Issue Possible Cause
User logged out randomly Session timeout, server restart, or sticky session issue
Session works on one node but fails on another No session replication or affinity
JWT gives 401 Unauthorized Expired token, invalid signature, wrong audience or issuer
Cookie not sent to server Wrong domain, path, Secure flag, or SameSite setting
High JVM memory usage Too many sessions or large session objects
Login loop Cookie, SSO, reverse proxy, or token validation issue

Key Takeaways

  • A cookie is browser-side storage.
  • A session stores user data on the server.
  • JSESSIONID is commonly stored inside a cookie.
  • JWT is a signed token used for stateless authentication.
  • Sessions are common in WebSphere, JBoss, and Tomcat applications.
  • JWT is common in APIs, Docker applications, microservices, and cloud-native systems.
  • Cookies, sessions, and JWT can all be secure or insecure depending on implementation.

What’s Next?

Next Article:
Part 6 – API Authentication & API Gateway Security

In the next article, we will understand API authentication methods such as API keys, Basic Authentication, JWT, OAuth2, and how API Gateways secure backend services.


Series: Authentication & Identity Security for Middleware, DevOps & Cloud Engineers
Author: Pradeep V
Blog: MiddlewareBox.com


14 Jun 2026

πŸ” What is Authentication in Web Applications? - Part 1

What is Authentication in Web Applications?

What is Authentication in Web Applications?

  • Welcome to the Authentication & Identity Security series.
  • This series is designed for Middleware, DevOps and Cloud Engineers.
  • Learn how authentication works in enterprise applications, APIs, cloud platforms, and Docker environments.
  • Includes real-world examples using LDAP, Active Directory, Azure Entra ID, WebSphere, and modern authentication technologies.


Introduction

Authentication is the first layer of security in any enterprise application. Before a user can access an application, API, cloud portal the system must verify the user's identity.

Whether you are managing IBM WebSphere, JBoss EAP, Apache Tomcat, Azure, Docker, or API Gateways, authentication is a critical component of enterprise security architecture.

Why is Authentication Important?
Authentication prevents unauthorized access to applications, APIs, cloud resources, and sensitive business data.

What is Authentication?

Authentication is the process of verifying the identity of a user, application, or system before granting access to resources.

Simply put:

Authentication answers the question:
"Who are you?"

Applications typically validate user credentials against:

  • LDAP
  • Microsoft Active Directory
  • Azure Entra ID
  • Database
  • Identity Providers

How Authentication Works

User
 │
 ▼
Login Page
 │
 ▼
Username & Password
 │
 ▼
Application Server
 │
 ▼
LDAP / AD / Azure Entra ID
 │
 ▼
Identity Verification
 │
 ▼
Session or Token Created
 │
 ▼
Access Granted

Once authentication is successful, the application creates a session or issues a token to establish trust between the user and the application.


Authentication vs Authorization

Authentication Authorization
Verifies identity Verifies permissions
Who are you? What can you access?
Occurs first Occurs after authentication
Login process Access control process

Enterprise Example

A user logs into the Azure Portal.

Authentication checks:

Is this user really Pradeep?

Authorization checks:

Can the user create Virtual Machines?
Can the user modify NSGs?
Can the user access Production Resources?

Enterprise Example: LDAP Authentication

Many traditional enterprise applications use LDAP or Active Directory for centralized authentication.

Architecture

User Browser
      │
      ▼
IBM HTTP Server / NGINX
      │
      ▼
WebSphere Application Server
      │
      ▼
LDAP / Active Directory

Authentication Flow

  1. User accesses the application.
  2. User enters username and password.
  3. WebSphere receives the login request.
  4. WebSphere sends credentials to LDAP.
  5. LDAP validates the credentials.
  6. WebSphere creates a session.
  7. Browser receives a JSESSIONID cookie.
  8. User gains access to the application.

Real-World Example

Application:
https://www.company.com

LDAP Server:
ldap://ldap.company.com:389

Successful Login Response:
Set-Cookie: JSESSIONID=ABC123XYZ789
Key Learning:
LDAP verifies whether the user exists and whether the supplied credentials are valid.

Enterprise Example: Azure Entra ID Authentication

Modern cloud-native applications use Azure Entra ID for centralized identity and access management.

Architecture

User
 │
 ▼
Web Application
 │
 ▼
Azure Entra ID
 │
 ▼
MFA Verification
 │
 ▼
JWT Token
 │
 ▼
Application Access

Authentication Flow

  1. User opens the application.
  2. Application redirects the user to Azure Entra ID.
  3. User enters credentials.
  4. Multi-Factor Authentication is completed.
  5. Azure Entra ID validates the identity.
  6. JWT token is issued.
  7. User is redirected back to the application.
  8. Application validates the token and grants access.

Benefits

  • Single Sign-On
  • Multi-Factor Authentication
  • Centralized Identity Management
  • Conditional Access Policies
  • Improved security posture

Traditional vs Modern Authentication

Traditional Authentication Modern Authentication
LDAP Azure Entra ID
Active Directory Identity Provider
Session-Based Token-Based
JSESSIONID JWT
Stateful Stateless
WebSphere / JBoss / Tomcat Cloud & Microservices
On-Premises Hybrid & Cloud

Why Authentication Matters

Authentication protects critical enterprise systems and reduces the risk of unauthorized access.

  • Enterprise applications
  • APIs
  • Customer data
  • Cloud resources
  • Docker
  • Administrative portals

Common authentication-related issues handled by Middleware and DevOps teams include:

  • LDAP connectivity failures
  • Active Directory integration issues
  • Login failures
  • Session timeout problems
  • SSO redirection loops
  • Expired JWT tokens
  • OAuth2 configuration issues
  • Azure Entra ID authentication failures
  • Load balancer session affinity issues

Key Takeaways

  • Authentication verifies identity before access is granted.
  • Authorization determines what an authenticated user can access.
  • Traditional enterprise applications commonly use LDAP, Active Directory, sessions, and cookies.
  • Modern applications use Azure Entra ID, JWT tokens, OAuth2, OIDC, and MFA.
  • Authentication is the first layer of security for applications, APIs, and cloud platforms.
  • Understanding authentication is essential for Middleware, DevOps, Cloud, and Security Engineers.

What’s Next?

Next Article:
Part 2 – Sessions, Cookies & JSESSIONID Explained

In the next article, we will understand how applications maintain user identity after successful authentication and how session management works in WebSphere, JBoss, Tomcat, and modern web applications.


Series: Authentication & Identity Security for Middleware, DevOps & Cloud Engineers
Author: Pradeep V
Blog: MiddlewareBox.com