🛡️ Automating SSL Certificate Access and Distribution using Forms and Power Automate.

⏱ Estimated reading time: 5 minutes

• Automate SSL certificate requests and sharing within your organization.
• Uses Microsoft Forms, Power Automate, SharePoint Online, and Exchange Online.
• Includes email validation, approval, access assignment, and secure delivery.
• Designed for Microsoft 365, Middleware, DevOps, and Enterprise Support teams.

---

Table of Contents

• Introduction
• Business Challenge
• Solution Overview
• Power Automate Workflow Diagram
• Step 1: Certificate Request Form
• Step 2: Organizational Email Validation
• Step 3: Approval Workflow
• Step 4: Automated Certificate Distribution
• Step 5: SharePoint Access Assignment
• Security Design
• Key Takeaways

---

Introduction

Manual SSL certificate sharing often requires repeated emails, approvals, permission changes, and file transfers. This becomes difficult to manage when many applications and users are involved.

Using Microsoft Forms and Power Automate, the process can be standardized from request submission to approval, SharePoint access, and certificate delivery.

Key Concept:
Automation reduces manual effort while approval and access controls keep certificate sharing secure and auditable.

---

Business Challenge

The manual process introduced several operational and security challenges:

• Requester details were verified manually.
• Requests did not follow a standard format.
• Approvals and delivery required repeated follow-ups.
• Sensitive files could be shared through uncontrolled channels.
• Tracking request, approval, and delivery history was difficult.

---

Solution Overview

Microsoft Forms collects the request, Power Automate manages the workflow, SharePoint Online stores the certificate, and Outlook sends notifications.

Component	Purpose
Microsoft Forms	Captures certificate request details.
Power Automate	Manages validation, approval, access, and delivery.
Approval Connector	Sends the request to the Certificate Administrator.
SharePoint Online	Stores certificate files and manages reader access.
Exchange Online / Outlook	Sends certificate, private key, and rejection emails.

---

Power Automate Workflow Diagram

The flow validates the requester before approval. Approved requests receive the certificate and SharePoint access, while rejected or unauthorized requests are stopped.

F Microsoft Forms

When a New Response is Submitted Microsoft Forms Trigger

F Microsoft Forms

Get Response Details Retrieve Name, Email ID, Application Name

Condition 1

Validate Organization Email Domain

True

A Approvals

Start and Wait for an Approval Approval request sent to Certificate Administrator

Condition 2

Check Approval Outcome

True

O Office 365 Outlook

Send an Email (V2) 1 Certificate file and SharePoint path access

O Office 365 Outlook

Send an Email (V2) 2 Private key file

False

O Office 365 Outlook

Send an Email (V2) Request rejection notification

False

■ Control

Terminate Invalid or unauthorized email domain

Workflow Logic:
A valid corporate email proceeds to approval. Approved requests receive the certificate and private key through separate emails. Rejected or invalid requests do not receive access.

---

Step 1: Certificate Request Form

Users submit requests through Microsoft Forms. The form captures:

• Requester Name
• Email Address
• Application Name

Submitting the form automatically starts the Power Automate flow.

---

Step 2: Organizational Email Validation

Power Automate verifies that the requester belongs to an approved corporate domain.

endsWith(emailAddress,'@company.com')

Security Control:
Requests from non-approved email domains are terminated automatically.

---

Step 3: Approval Workflow

After validation, the Certificate Administrator receives an approval request containing:

• Requester Name
• Email Address
• Application Name
• Request Timestamp

The administrator selects Approve or Reject. No certificate or private key is sent until the request is approved.

---

Step 4: Automated Certificate Distribution

After approval, Power Automate sends two separate emails.

Email 1 – Certificate Delivery

Subject: Certificate Request Approved

Attachments:
certificate.crt
certificate.pem

Body:
Your certificate request has been approved.
SharePoint read access has been granted.

Email 2 – Private Key Delivery

Subject: Private Key File

Attachment:
privatekey.key

Body:
Please find the private key file attached.
This file is confidential and should be stored securely.

Security Best Practice:
Use encryption, password-protected files, restricted access, or secure vault-based storage for stronger protection.

---

Step 5: SharePoint Access Assignment

After approval, Power Automate grants Reader access to the relevant SharePoint library or folder and sends the repository link.

User Approved
      │
      ▼
Power Automate
      │
      ▼
Grant SharePoint Reader Access
      │
      ▼
Send Repository Link

This removes manual permission assignment and ensures access is granted only after approval.

---

Security Design

Control	Purpose
Email Domain Validation	Blocks external or unauthorized requests.
Approval Workflow	Ensures certificate sharing is authorized.
Separate Email Delivery	Reduces exposure of the certificate and private key together.
SharePoint Reader Access	Provides controlled repository access.
Power Automate Run History	Tracks each workflow execution.
Approval History	Records approval and rejection decisions.

Enterprise Recommendation:
Store certificate files and private keys in separate secured repositories and retain request, approval, and access logs.

---

Key Takeaways

• Microsoft Forms provides a standard request portal.
• Power Automate manages validation, approval, and delivery.
• SharePoint provides controlled certificate access.
• Certificate and private key files are delivered separately.
• The solution improves security, efficiency, and auditability.

---

Real-World Outcome:
A manual email-based activity becomes a secure, automated, and auditable SSL certificate sharing process.

---

Category: Microsoft 365 Automation, Power Automate, SharePoint Online, Enterprise Security, SSL Certificate
Author: Pradeep V
Blog: MiddlewareBox.com

---

🏢 Enterprise Authentication & Identity Security Series

🔐 Authentication & Identity Security Series for Middleware, DevOps & Cloud Engineers

Welcome to the Authentication & Identity Security Series

This 10-part series is designed for Middleware Engineers, DevOps Engineers, Cloud Engineers, Security Engineers and Application Support Teams who want to understand modern authentication, authorization, API security, identity management, and Zero Trust architecture.

Whether you work with WebSphere, JBoss, Tomcat, Microsoft Entra ID, Azure, APIs, or enterprise applications, this series will help you understand authentication from traditional session-based applications to modern cloud-native identity platforms.

---

---

---

---

---

📚 Complete Authentication & Identity Security Roadmap

Part	Topic	Summary
Part 1	🔐 What is Authentication?	Authentication basics, Authorization, login flow, and modern authentication concepts.
Part 2	🆔 Sessions, Cookies & JSESSIONID	Learn how applications maintain user state using sessions, cookies, and JSESSIONID.
Part 3	⚖️ Stateful vs Stateless Applications	Understand traditional session-based applications versus stateless cloud-native applications.
Part 4	🎫 JWT & Token-Based Authentication	JWT structure, bearer tokens, access tokens, refresh tokens, and token-based security.
Part 5	📊 JWT vs Session vs Cookies Explained	Compare Sessions, Cookies, and JWT authentication mechanisms.
Part 6	🚪 API Authentication & API Gateway Security	API keys, OAuth2, JWT validation, API gateways, and enterprise API security.
Part 7	🔄 OAuth2, OIDC & SAML Explained	Enterprise identity protocols used in SSO and federation.
Part 8	☁️ SSO, MFA & Microsoft Entra ID	Single Sign-On, Multi-Factor Authentication, Conditional Access, and Entra ID.
Part 9	🟦 WebSphere LTPA, Sticky Sessions & Session Replication	Enterprise middleware authentication, clustering, session management, and high availability.
Part 10	🛡️ Zero Trust Security & Authentication Risks	Zero Trust, Zscaler, PAM, SIEM, phishing, token theft, and modern security controls.

---

---

---

---

📌 Key Technologies Covered

Category	Technologies / Concepts	Purpose
Authentication	Authentication, Authorization	User identity verification and access control
Session Management	Sessions, Cookies, JSESSIONID	Maintaining user state in web applications
Token Security	JWT, Access Tokens, Refresh Tokens	Stateless authentication and API security
Identity Protocols	OAuth2, OIDC, SAML	Enterprise identity federation and authentication
Identity Management	SSO, MFA, Microsoft Entra ID	Identity governance and access management
API Security	API Authentication, API Gateway	Protecting APIs and microservices
Middleware Security	WebSphere LTPA, Sticky Sessions, Session Replication	Middleware authentication and high availability
Cloud Security	Conditional Access, Risk-Based Authentication	Cloud-native security controls
Zero Trust	ZTNA, SASE, Zero Trust Architecture	Identity-driven security model
Security Platforms	Zscaler, CyberArk, BeyondTrust	Enterprise security and PAM solutions
Monitoring	SIEM, Microsoft Sentinel, Splunk, QRadar	Security monitoring and threat detection
Middleware Platforms	WebSphere, JBoss, Tomcat	Enterprise application hosting platforms

---

---

---

🚀 Start Learning

New to Authentication and Identity Security? Start with:

👉 Part 1 - What is Authentication?

---

Author: Pradeep V
Blog: MiddlewareBox.com

🍪 Sessions, Cookies & JSESSIONID Explained - Part 2

• Welcome to Part 2 of the Authentication & Identity Security series.
• This article explains how applications remember users after successful login.
• Designed for Middleware, DevOps, Cloud, and Application Support Engineers.
• Includes enterprise examples using WebSphere, Tomcat, JBoss, IBM HTTP Server, NGINX, and Load Balancers.

---

Table of Contents

• Introduction
• What is a Session?
• How WebSphere, JBoss, Tomcat & Docker Store Session Data
• What is a Cookie?
• What is JSESSIONID?
• How Session Management Works
• Enterprise Example: WebSphere Session Flow
• Sessions Through Load Balancers
• Session vs Cookie vs JSESSIONID
• Session Security Best Practices
• Common Session Issues
• Key Takeaways
• What’s Next?

---

Introduction

In Part 1, we learned that authentication verifies a user's identity. After authentication is successful, the next important question is: how does the application remember the same user during future requests?

This is where Sessions, Cookies, and JSESSIONID come into the picture. These components help enterprise applications maintain user identity after login without asking the user to authenticate again on every page.

Key Concept:
Authentication verifies the user once, while session management maintains the user's identity throughout the application journey.

---

What is a Session?

A session is a server-side mechanism used to store user-specific information after successful authentication.

When a user logs in, the application server creates a unique session for that user. The session may store information such as:

• User ID
• User role
• Login time
• Application permissions
• User preferences

The session remains active until one of the following events occurs:

• User logs out
• Session timeout occurs
• Application server restarts
• Session is invalidated by the application

Middleware View:
In WebSphere, JBoss, and Tomcat, sessions are usually stored in application server memory unless session persistence or replication is configured.

---

How Do WebSphere, JBoss, Tomcat & Docker Store Session Data?

By default, Java application servers store session data in JVM heap memory. The browser only stores the session identifier (JSESSIONID), while the actual user session data remains on the application server.

Platform	Default Session Storage	High Availability Options
IBM WebSphere	JVM Heap Memory	Memory-to-Memory Replication, Database Persistence
JBoss EAP / WildFly	JVM Heap Memory	Session Replication, Infinispan Cache
Apache Tomcat	JVM Heap Memory	Session Persistence, Redis, Session Replication
Docker Containers	Inside Application JVM/Process	Redis, Database, Sticky Sessions, External Session Store

Docker Session Storage

Browser
   │
JSESSIONID
   │
Docker Container
   │
Tomcat / JBoss / WebSphere Liberty
   │
JVM Heap Memory

Docker itself does not manage user sessions. Sessions are managed by the application running inside the container.

If a container is restarted, redeployed, or scaled down, in-memory sessions may be lost unless external session storage is configured.

Docker Best Practice:
Use Redis, database persistence, sticky sessions, or JWT-based authentication for better scalability and resilience.

---

What is a Cookie?

A cookie is a small piece of data stored in the user's browser. Applications use cookies to identify users across multiple HTTP requests.

HTTP is stateless by default. This means every request is independent. Without cookies or tokens, the server cannot easily identify whether two requests are coming from the same user.

After successful login, the server sends a cookie to the browser.

Set-Cookie: JSESSIONID=ABC123XYZ789

For every next request, the browser automatically sends this cookie back to the server.

Cookie: JSESSIONID=ABC123XYZ789

---

What is JSESSIONID?

JSESSIONID is the default session identifier used by Java-based application servers.

It is commonly seen in applications running on:

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

JSESSIONID does not usually store the full user data. It acts as a reference ID that helps the application server locate the correct server-side session.

JSESSIONID=ABC123XYZ789

Important:
The actual session data is normally stored on the server side. The browser usually stores only the session identifier.

---

How Session Management Works

User
 │
 ▼
Login Page
 │
 ▼
Authentication Successful
 │
 ▼
Application Server Creates Session
 │
 ▼
JSESSIONID Generated
 │
 ▼
Cookie Sent To Browser
 │
 ▼
Browser Sends Cookie With Every Request
 │
 ▼
Application Server Retrieves Session
 │
 ▼
User Continues Application Access

This process allows the application to remember the authenticated user until logout or session timeout.

---

Enterprise Example: WebSphere Session Flow

Architecture

User Browser
      │
      ▼
IBM HTTP Server
      │
      ▼
WebSphere Application Server
      │
      ▼
Enterprise Application

Session Flow

1. User accesses the application login page.
2. User enters username and password.
3. WebSphere authenticates the user using LDAP or Active Directory.
4. WebSphere creates a session in application server memory.
5. WebSphere generates a JSESSIONID.
6. Browser receives the JSESSIONID as a cookie.
7. Browser sends the same cookie in every future request.
8. WebSphere uses JSESSIONID to locate the user's session.

Example HTTP Response

HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=ABC123XYZ789; Path=/app; HttpOnly; Secure

Example HTTP Request

GET /app/dashboard HTTP/1.1
Host: www.company.com
Cookie: JSESSIONID=ABC123XYZ789

---

Sessions Through Load Balancers

In enterprise environments, applications often run on multiple servers behind a load balancer.

User Browser
      │
      ▼
NGINX / IBM HTTP Server / F5 / Azure Load Balancer
      │
      ▼
 ┌───────────────┬───────────────┐
 │ WebSphere-01  │ WebSphere-02  │
 └───────────────┴───────────────┘

If a user logs in through WebSphere-01 but the next request goes to WebSphere-02, the session may not be available on WebSphere-02 unless session replication or sticky session is configured.

Common Solutions

• Sticky Session: Route the same user to the same backend server.
• Session Replication: Copy session data across cluster members.
• External Session Store: Store sessions in Redis, database, or distributed cache.

Production Tip:
For stateful Java applications, session affinity is commonly configured at IBM HTTP Server, NGINX, F5, or application server plugin level.

---

Session vs Cookie vs JSESSIONID

Component	Purpose	Stored In	Example
Session	Stores user-specific data	Application Server	User ID, role, login time
Cookie	Stores small client-side data	Browser	JSESSIONID cookie
JSESSIONID	Identifies the server-side session	Browser cookie or URL	ABC123XYZ789

---

Session Security Best Practices

Session security is very important because attackers may try to steal or misuse session identifiers.

• Use Secure flag so cookies are sent only over HTTPS.
• Use HttpOnly flag to reduce JavaScript-based cookie theft.
• Use SameSite attribute to reduce CSRF risk.
• Regenerate session ID after successful login.
• Configure proper session timeout.
• Invalidate session during logout.
• Avoid exposing JSESSIONID in URLs.

Recommended Cookie Example

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

---

Common Session Issues

Middleware and DevOps teams commonly troubleshoot session-related issues in production environments.

Issue	Possible Cause
User logged out unexpectedly	Session timeout or server restart
Session lost after login	Cookie not stored or wrong cookie path
Intermittent logout in cluster	Sticky session or replication issue
JSESSIONID not visible	Application not creating session
Cookie not sent over HTTPS	Secure flag or domain/path mismatch
Login loop	SSO, cookie, or reverse proxy issue

---

Key Takeaways

• Authentication verifies identity.
• Sessions maintain user identity after login.
• Cookies store identifiers in the browser.
• JSESSIONID is the default session identifier for Java applications.
• Session affinity and replication are important in clustered environments.
• Cookie security flags such as Secure, HttpOnly, and SameSite improve session security.
• Session management is critical for WebSphere, JBoss, Tomcat, and enterprise applications.

---

What’s Next?

Next Article:
Part 3 – Stateful vs Stateless Applications

In the next article, we will understand the difference between stateful and stateless applications and why this concept is important for scaling enterprise applications, APIs, and cloud workloads.

---

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

---

🚫 Zero Trust Security & Authentication Risks Explained - Part 10

• Welcome to Part 10 and the final article of the Authentication & Identity Security series.
• This article summarizes the complete series and explains Zero Trust Security, authentication risks, and modern enterprise security tools.
• Designed for Middleware, DevOps, Cloud, Security, and Application Support Engineers.
• Includes examples using Microsoft Entra ID, Zscaler, Conditional Access, PAM, SIEM, CyberArk, Microsoft Sentinel, OAuth2, JWT, sessions, and enterprise applications.

---

Table of Contents

• Authentication Series Summary
• Common Terms Used in This Article
• What is Zero Trust Security?
• Why Zero Trust Became Important
• Core Principles of Zero Trust
• Popular Zero Trust and Security Tools
• Zscaler Zero Trust Example
• Microsoft Entra ID + Zscaler Example
• Zero Trust Pillars
• Common Authentication Risks
• Token Theft and Session Hijacking
• PAM and Privileged Access Security
• SIEM and Security Monitoring
• Microsoft Entra ID Security Features
• Market Trend and Career Skills
• Best Practices
• Interview Questions
• Key Takeaways

---

Authentication & Identity Security Series Summary

This article concludes the complete Authentication & Identity Security series. Below is a quick summary of all 10 parts.

Part	Topic	Key Learning
Part 1	Authentication Basics	Authentication vs Authorization and enterprise login flow
Part 2	Sessions, Cookies & JSESSIONID	How applications remember users after login
Part 3	Stateful vs Stateless Applications	Traditional sessions vs stateless token-based architecture
Part 4	JWT & Token-Based Authentication	JSON Web Token structure, access tokens, refresh tokens, and bearer tokens
Part 5	JWT vs Session vs Cookies	Difference between browser cookies, server sessions, and JWT tokens
Part 6	API Authentication & API Gateway Security	API keys, Basic Authentication, JWT, OAuth2, API Gateway, and security controls
Part 7	OAuth2, OIDC & SAML	Enterprise authentication protocols and SSO integration
Part 8	SSO, MFA & Microsoft Entra ID	Single Sign-On, Multi-Factor Authentication, Conditional Access, and Entra ID integration
Part 9	WebSphere LTPA, Sticky Sessions & Session Replication	Traditional middleware session management and high availability
Part 10	Zero Trust Security & Authentication Risks	Modern identity security, risk reduction, monitoring, and enterprise security tools

---

Common Terms Used in This Article

Term	Full Form / Meaning
Zero Trust	Never Trust, Always Verify security model
ZTNA	Zero Trust Network Access
SASE	Secure Access Service Edge
MFA	Multi-Factor Authentication
SSO	Single Sign-On
IAM	Identity and Access Management
PAM	Privileged Access Management
SIEM	Security Information and Event Management
JWT	JSON Web Token
OAuth2	Open Authorization 2.0
ZIA	Zscaler Internet Access
ZPA	Zscaler Private Access
CASB	Cloud Access Security Broker

---

What is Zero Trust Security?

Zero Trust Security is a modern security model based on the principle:

Never Trust, Always Verify

In Zero Trust, every user, device, application, API request, and network connection must be verified before access is granted.

User
 │
 ▼
Identity Verification
 │
 ▼
Device Verification
 │
 ▼
Risk Evaluation
 │
 ▼
Policy Validation
 │
 ▼
Application Access

Zero Trust does not automatically trust users just because they are inside the corporate network or connected through VPN.

---

Why Zero Trust Became Important

Traditional security assumed that users and systems inside the corporate network were trusted.

Traditional Model

Inside Network  = Trusted
Outside Network = Untrusted

This model is no longer enough because modern enterprises use cloud, SaaS applications, remote work, APIs, mobile devices, containers, and third-party integrations.

Modern Enterprise Environment

Remote Users
Cloud Applications
Mobile Devices
APIs
SaaS Platforms
Docker Containers
Hybrid Infrastructure

Zero Trust became important because identity, device posture, application access, and continuous verification are now more important than network location.

---

Core Principles of Zero Trust

Principle	Meaning
Verify Explicitly	Validate identity, device, location, risk, and application access every time.
Least Privilege Access	Give users only the minimum access required for their role.
Assume Breach	Design security assuming attackers may already be inside the environment.
Continuous Monitoring	Monitor sign-ins, sessions, token usage, privileged actions, and security events.
Strong Authentication	Use MFA, passwordless authentication, device compliance, and risk-based policies.

---

Popular Zero Trust and Security Tools

Many enterprises are investing heavily in Zero Trust, SASE, ZTNA, PAM, and SIEM platforms.

Vendor	Product / Platform	Common Usage
Zscaler	ZIA / ZPA	Zero Trust Network Access, secure internet access, private application access
Palo Alto Networks	Prisma Access	SASE and cloud-delivered security
Cloudflare	Cloudflare Zero Trust	ZTNA, secure web gateway, access control
Microsoft	Microsoft Entra ID / Conditional Access	Identity-based Zero Trust, MFA, risk-based access
Okta	Okta Identity Cloud	Identity security, SSO, MFA, lifecycle management
CyberArk	CyberArk PAM	Privileged Access Management and administrator account protection
BeyondTrust	BeyondTrust PAM	Privileged account security and session control
Microsoft	Microsoft Sentinel	SIEM and security monitoring
Splunk	Splunk Enterprise Security	SIEM, log analytics, threat detection

---

Zscaler Zero Trust Example

Zscaler is widely used in enterprises for Zero Trust and secure access. Two common Zscaler products are:

• ZIA (Zscaler Internet Access): Secure internet and SaaS access.
• ZPA (Zscaler Private Access): Secure private application access without traditional VPN exposure.

Traditional VPN Model

User
 │
 ▼
VPN
 │
 ▼
Corporate Network
 │
 ▼
Application Access

In a traditional VPN model, once a user connects to the corporate network, they may get broad network-level access.

Zscaler ZPA Model

User
 │
 ▼
Identity Verification
 │
 ▼
Device Posture Check
 │
 ▼
Zscaler ZPA
 │
 ▼
Specific Private Application

With ZPA, users do not get full network access. They get access only to the specific application they are authorized to use.

Why Zscaler Is Popular:
Enterprises are moving away from traditional VPN-based access toward application-level access, identity verification, device validation, and Zero Trust Network Access.

---

Microsoft Entra ID + Zscaler Example

Microsoft Entra ID and Zscaler are commonly integrated in enterprise environments.

User
 │
 ▼
Microsoft Entra ID
 │
 ▼
MFA Validation
 │
 ▼
Conditional Access Policy
 │
 ▼
Zscaler ZPA
 │
 ▼
Private Enterprise Application

Access Checks

• User identity is validated using Microsoft Entra ID.
• MFA is enforced for high-risk applications.
• Conditional Access checks location, device, and risk.
• Zscaler validates access to private applications.
• User gets access only to approved applications.

Enterprise Use Case

Remote User
  │
  ▼
Microsoft Entra ID Login
  │
  ▼
MFA + Conditional Access
  │
  ▼
Zscaler Private Access
  │
  ▼
Internal HR / Finance / Middleware Portal

---

Zero Trust Pillars

Pillar	Example Tool / Technology	Purpose
Identity	Microsoft Entra ID, Okta	Authenticate users and enforce access policies
Device	Microsoft Intune	Validate device compliance and health
Network	Zscaler, Prisma Access, Cloudflare Zero Trust	Secure user access without broad network trust
Application	Azure Application Gateway, API Gateway	Protect application access and APIs
Data	Microsoft Purview	Classify and protect sensitive data
Monitoring	Microsoft Sentinel, Splunk, QRadar	Detect threats and monitor security events
Privileged Access	CyberArk, BeyondTrust, Entra PIM	Protect administrator and privileged accounts

---

Common Authentication Risks

Risk	Description	Control
Phishing	Fake login pages steal user credentials.	MFA, phishing-resistant authentication, user awareness
Password Spray	Attackers try common passwords against many users.	Account lockout, MFA, risk-based detection
Brute Force	Repeated password attempts against an account.	Lockout policy, MFA, monitoring
Token Theft	OAuth2 or JWT tokens are stolen and reused.	Short token expiry, secure storage, Conditional Access
Session Hijacking	Session identifiers such as JSESSIONID are stolen.	Secure, HttpOnly, SameSite cookies and HTTPS
Privilege Escalation	User gains higher access than required.	Least privilege, PAM, access reviews
Weak Service Account Security	Shared or unmanaged service accounts are abused.	Managed identity, secret rotation, PAM

---

Token Theft and Session Hijacking

Token Theft Example

User Login
 │
 ▼
OAuth2 / JWT Token Issued
 │
 ▼
Token Stolen
 │
 ▼
Attacker Uses Token
 │
 ▼
Unauthorized API Access

Session Hijacking Example

User Session
 │
 ▼
JSESSIONID Cookie
 │
 ▼
Cookie Stolen
 │
 ▼
Attacker Reuses Session
 │
 ▼
Unauthorized Application Access

Protection Controls

• Use HTTPS everywhere.
• Use Secure, HttpOnly, and SameSite cookie flags.
• Keep access tokens short-lived.
• Validate issuer, audience, expiry, and signature.
• Use Conditional Access and device compliance policies.
• Monitor abnormal sign-in and token usage patterns.

---

PAM and Privileged Access Security

PAM (Privileged Access Management) protects administrator accounts, root accounts, database admin accounts, service accounts, and other high-risk identities.

Common PAM Capabilities

• Password vaulting
• Privileged session recording
• Just-In-Time access
• Approval workflows
• Credential rotation
• Audit tracking

Example PAM Flow

Admin User
   │
   ▼
PAM Portal
   │
   ▼
Approval / MFA
   │
   ▼
Temporary Privileged Access
   │
   ▼
Session Recorded

CyberArk, BeyondTrust, and Microsoft Entra Privileged Identity Management are commonly used for privileged access controls.

---

SIEM and Security Monitoring

SIEM (Security Information and Event Management) platforms collect logs from identity systems, servers, applications, firewalls, API gateways, and cloud platforms to detect suspicious activity.

Common SIEM Sources

• Microsoft Entra ID sign-in logs
• Azure activity logs
• Application authentication logs
• API Gateway logs
• WebSphere / Tomcat / JBoss logs
• Firewall and proxy logs
• Zscaler access logs

Example Monitoring Flow

Authentication Logs
       │
       ▼
Microsoft Sentinel / Splunk / QRadar
       │
       ▼
Correlation Rules
       │
       ▼
Alert / Incident
       │
       ▼
Security Investigation

---

Microsoft Entra ID Security Features

• MFA (Multi-Factor Authentication)
• Conditional Access
• Identity Protection
• Risk-based sign-in detection
• Passwordless authentication
• Privileged Identity Management
• Access reviews
• Application SSO integration
• Audit logs and sign-in logs

Microsoft Entra ID Zero Trust Flow

User
 │
 ▼
Microsoft Entra ID
 │
 ▼
MFA
 │
 ▼
Conditional Access
 │
 ▼
Risk Evaluation
 │
 ▼
Application Access
 │
 ▼
Continuous Monitoring

---

Market Trend and Career Skills

Enterprises are moving from traditional VPN and network-based trust to identity-based security and Zero Trust.

Old Model

VPN
Firewall
Network Trust

Modern Model

Identity-Based Security
Zero Trust Network Access
Continuous Verification
Application-Level Access

Skills around Zero Trust, Zscaler, Microsoft Entra ID, Conditional Access, OAuth2, OIDC, SAML, PAM, and SIEM are highly valued in enterprise infrastructure, cloud, security, and DevOps roles.

High-Demand Skills

• Microsoft Entra ID
• Conditional Access
• MFA and SSO
• OAuth2, OIDC, and SAML
• Zscaler ZIA and ZPA
• CyberArk or BeyondTrust PAM
• Microsoft Sentinel or Splunk SIEM
• API Gateway security
• Authentication troubleshooting

---

Best Practices

• Enable MFA for all privileged and high-risk accounts.
• Use Conditional Access policies for sensitive applications.
• Apply least privilege access across users, groups, and applications.
• Use Zero Trust Network Access instead of broad VPN access where possible.
• Protect tokens and sessions using secure storage and short expiry.
• Use PAM for administrator, root, and service accounts.
• Monitor identity logs using SIEM tools.
• Review access permissions periodically.
• Rotate secrets, certificates, and signing keys regularly.
• Document authentication flows for applications and APIs.

---

Interview Questions

What is Zero Trust?

Zero Trust is a security model based on the principle "Never Trust, Always Verify". Every user, device, application, and request must be verified before access is granted.

What is ZTNA?

ZTNA (Zero Trust Network Access) provides secure application access without giving users broad network-level access like traditional VPN.

Why is Zscaler used in enterprises?

Zscaler is commonly used to provide secure internet access, private application access, Zero Trust Network Access, and cloud-delivered security controls for remote and enterprise users.

What is the difference between VPN and ZTNA?

VPN usually provides network-level access. ZTNA provides application-level access based on identity, device posture, and policy validation.

How do you protect JWT tokens and sessions?

Use HTTPS, short token expiry, secure cookie flags, token validation, Conditional Access, device compliance, and monitoring for abnormal usage.

---

Key Takeaways

• Zero Trust means Never Trust, Always Verify.
• Modern enterprise security is identity-driven, not only network-driven.
• Zscaler, Microsoft Entra ID, CyberArk, Microsoft Sentinel, and similar tools are important in modern security architecture.
• ZTNA provides application-level access instead of broad VPN access.
• MFA, Conditional Access, PAM, and SIEM are critical security controls.
• Authentication risks include phishing, token theft, session hijacking, and privilege escalation.
• Middleware, DevOps, and Cloud Engineers should understand identity, sessions, tokens, API security, and Zero Trust concepts.

---

Series Completed

---

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

---

🌐 WebSphere LTPA, Sticky Sessions & Session Replication Explained - Part 9

Welcome to Part 9 of the Authentication & Identity Security Series. This article explains LTPA (Lightweight Third-Party Authentication), JSESSIONID (Java Session Identifier), Sticky Sessions, Session Replication, and session handling in WebSphere, Tomcat, JBoss and Docker environments.

---

Table of Contents

• What is LTPA?
• How WebSphere Authentication Works
• LTPA vs JSESSIONID
• What are Sticky Sessions?
• Sticky Sessions vs Session Replication
• Session Replication in WebSphere
• Session Handling in Tomcat
• Session Handling in JBoss
• Docker Session Challenges
• Common Production Issues
• Interview Questions
• Best Practices

---

Common Terms Used in This Article

Abbreviation	Full Form
LTPA	Lightweight Third-Party Authentication
JSESSIONID	Java Session Identifier
IHS	IBM HTTP Server
WAS	WebSphere Application Server
JVM	Java Virtual Machine
HA	High Availability
DR	Disaster Recovery
SSL	Secure Sockets Layer

---

What is LTPA (Lightweight Third-Party Authentication)?

LTPA (Lightweight Third-Party Authentication) is IBM's authentication token mechanism used by WebSphere Application Server to provide authentication and Single Sign-On across applications.

User Login
    │
    ▼
WebSphere Authentication
    │
    ▼
LTPA Token Generated
    │
    ▼
Browser Stores LTPA Cookie
    │
    ▼
Future Requests Use LTPA Token

LTPA is mainly used for Authentication and Single Sign-On.

---

How WebSphere Authentication Works

User Browser
      │
      ▼
IBM HTTP Server (IHS)
      │
      ▼
WebSphere Application Server
      │
      ▼
LDAP / Microsoft Entra ID / AD
      │
      ▼
Authentication Success

After successful authentication, WebSphere generates an LTPA token and session information.

---

LTPA vs JSESSIONID

Feature	LTPA	JSESSIONID
Purpose	Authentication	Session Tracking
Used For	SSO	User Session
Generated After	Login	Session Creation
WebSphere Specific	Yes	No

LTPA identifies who the user is, while JSESSIONID identifies the user's application session.

---

What are Sticky Sessions?

Sticky Session (Session Affinity) ensures that a user continues to connect to the same application server node.

Load Balancer
      │
      ├── JVM1  ← User Always Routed Here
      │
      └── JVM2

Advantages

• Simple configuration
• Better performance
• No replication overhead

Disadvantages

• If JVM crashes, user session may be lost
• Not ideal for HA environments

---

Sticky Sessions vs Session Replication

Feature	Sticky Session	Session Replication
Performance	High	Medium
Failover Support	Limited	Excellent
Complexity	Low	High
HA Support	Partial	Strong

---

Session Replication in WebSphere

Memory-to-Memory Replication

JVM1
 ↔
JVM2

Database Session Persistence

JVM1
 │
 ▼
Session Database
 │
 ▼
JVM2

If JVM1 fails, JVM2 can continue serving requests using replicated session data.

---

Session Handling in Apache Tomcat

Browser
   │
JSESSIONID
   │
Tomcat JVM

Tomcat supports clustering using DeltaManager and BackupManager. External session stores such as Redis are commonly used.

---

Session Handling in JBoss EAP

Browser
   │
JSESSIONID
   │
JBoss Cluster

JBoss commonly uses Infinispan for distributed session replication.

---

Docker Session Challenges

User
 │
 ▼
Docker Container
 │
 ▼
Tomcat / JBoss / Liberty

If a container restarts, in-memory sessions can be lost.

Recommended Solutions

• JWT (JSON Web Token)
• Redis Session Store
• Database Session Store
• External Session Cache

---

Common Production Issues

Issue	Cause
Random Logout	Session Timeout
SSO Failure	LTPA Key Mismatch
Session Lost After Restart	In-Memory Session Storage
User Routed To Wrong Node	Load Balancer Affinity Issue
Session Replication Failure	Cluster Misconfiguration

---

Interview Question

What is the difference between LTPA and JSESSIONID?

LTPA (Lightweight Third-Party Authentication) is used for authentication and Single Sign-On, whereas JSESSIONID (Java Session Identifier) is used for session tracking and maintaining user state.

---

Best Practices

• Use sticky sessions only when failover is not critical.
• Enable session replication for HA applications.
• Synchronize LTPA keys across WebSphere cells.
• Use Redis or database-backed sessions in containers.
• Monitor session count and JVM memory usage.
• Configure proper session timeout values.
• Test failover regularly.

---

Key Takeaways

• LTPA provides WebSphere authentication and SSO.
• JSESSIONID tracks user sessions.
• Sticky sessions improve performance.
• Session replication improves availability.
• Docker requires external session management for HA.

---

What's Next?

Part 10 – Zero Trust Security & Authentication Risks

---

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

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

• 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.

---

Table of Contents

• Introduction
• Common Terms Used in This Article
• What is SSO (Single Sign-On)?
• What is MFA (Multi-Factor Authentication)?
• What is Microsoft Entra ID?
• Enterprise Authentication Flow
• SSO Protocols: OIDC (OpenID Connect) and SAML (Security Assertion Markup Language)
• Conditional Access
• How to Setup SSO (Single Sign-On) and MFA (Multi-Factor Authentication) in Microsoft Entra ID
• Middleware Application Integration Example
• SSO vs MFA vs Entra ID
• Common Issues
• Best Practices
• Key Takeaways
• What’s Next?

---

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
SSO	Single Sign-On
MFA	Multi-Factor Authentication
Microsoft Entra ID	Formerly Azure Active Directory
IAM	Identity and Access Management
OIDC	OpenID Connect
OAuth2	Open Authorization 2.0
SAML	Security Assertion Markup Language
JWT	JSON Web Token
ADFS	Active Directory Federation Services
API	Application 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

• 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.

---

Table of Contents

• Introduction
• What is OAuth2?
• What is OpenID Connect (OIDC)?
• What is SAML?
• OAuth2 vs OIDC
• OIDC vs SAML
• Azure Entra ID Example
• Enterprise SSO Architecture
• Access Token, ID Token & SAML Assertion
• Where OAuth2, OIDC and SAML are Used
• OAuth2 vs OIDC vs SAML Comparison
• How to Setup OAuth2, OIDC and SAML - Practical Example
• Common Issues
• Best Practices
• Key Takeaways
• What’s Next?

---

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

---