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 |
| 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
- Login to Microsoft Entra Admin Center.
- Go to Enterprise applications.
- Select or create the application.
- Open Single sign-on.
- Choose protocol: SAML or OIDC depending on application support.
- Configure Identifier, Reply URL, Redirect URI, or metadata.
- Configure user attributes and claims.
- Assign users or groups to the application.
- Test SSO login.
Example 2: Enable MFA
- Go to Microsoft Entra Admin Center.
- Open Protection or Conditional Access.
- Create a new Conditional Access policy.
- Select target users or groups.
- Select target application.
- Under Grant controls, choose Require multifactor authentication.
- Enable policy in report-only mode first.
- 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
