SSO - Single Sign-On
Single Sign-On (SSO) allows users to authenticate once and then access multiple applications and services without having to log in again. SSO is based on protocols such as SAML 2.0, OIDC/OAuth 2.0, and Kerberos. From a security perspective, SSO is a double-edged sword: it reduces password vulnerabilities, but a compromised SSO provider grants access to all connected services. Identity Providers (IdP): Azure AD/Entra ID, Okta, Ping Identity, Google Workspace.
Single Sign-On is the standard in modern enterprise environments—and a prime target for attackers. Anyone who compromises the identity provider potentially gains access to all connected applications without ever knowing a single password. SSO security is therefore not just a matter of convenience, but one of the most critical security decisions in the IAM portfolio.
SSO Technologies
SAML 2.0 (Security Assertion Markup Language)
- Use: Enterprise Web SSO (Legacy + Modern)
- Format: XML-based assertions
- Flow: SP-initiated or IdP-initiated
- Strengths: Widely used; all enterprise apps support it
- Weaknesses: Complex, XML security issues (XXE, XSW attacks!)
OIDC (OpenID Connect) / OAuth 2.0
- Use: Modern apps, APIs, mobile, cloud-native
- Format: JWT-based ID tokens
- Flow: Authorization Code + PKCE
- Strengths: Simpler, JSON-based, cloud-native
- Weaknesses: Complex token validation, many implementation errors
Kerberos
- Usage: Windows Active Directory (on-premise)
- Format: Ticket-based (TGT + Service Tickets)
- Strengths: Deep Windows integration, transparent to users
- Weaknesses: AD-only, complex, many attack vectors (Golden Ticket!)
LDAP SSO
- Usage: Internal Linux services (with OpenLDAP, AD LDAP)
- Format: Directory protocol
- Usage: Apache web server, Confluence, Jira (LDAP auth)
RADIUS
- Usage: VPN authentication, enterprise Wi-Fi (802.1X)
- Format: UDP-based authentication protocol
Passwordless SSO (modern)
- FIDO2/WebAuthn: Hardware keys (YubiKey) as SSO
- Passkeys: Device-bound private keys (no phishing possible!)
- Combination: Passkey → OIDC token → App SSO
Identity Provider Comparison
Microsoft Entra ID (formerly Azure AD)
- Market Share: ~50% Enterprise (due to M365 dominance)
- Strengths:
- M365-native integration (Teams, SharePoint, Exchange)
- Conditional Access: granular access rules
- Privileged Identity Management (PIM): Just-in-Time Admin
- Microsoft Authenticator: phishing-resistant MFA
- SSPR (Self-Service Password Reset) with multi-factor authentication
- Costs:
- Azure AD Free: Basic SSO (incl. M365)
- Entra ID P1: €6/user/month (Conditional Access, SSO for all apps)
- Entra ID P2: €9/user/month (PIM, Identity Protection)
Okta
- Market Share: Leading outside the Microsoft ecosystem
- Strengths:
- Universal Directory: Consolidate any user sources
- App Integration: 7,000+ preconfigured app connections
- Adaptive MFA: Risk-based authentication decisions
- Workflows: No-code identity automation
- Lifecycle Management (IGA functionality)
- Costs: Workforce Identity: starting at $2/user/month (SSO) up to $15+ (Advanced)
- Known issue: Okta itself was compromised in 2022/2023!
Google Workspace (Cloud Identity)
- Strengths:
- Seamless Google app integration
- Context-aware access: Device trust + location
- FIDO2 keys: Hardware key support by default
- Suitable for: Google Workspace companies
Ping Identity
- Strengths: Hybrid environments (on-premise + cloud)
- Special feature: PingFederate (on-premise SAML/OIDC IdP)
- Suitable for: Regulated industries, on-premise requirements
Keycloak (Open Source)
- Cost: Free (Red Hat SSO = Enterprise version)
- Deployment: Self-hosted (Docker/Kubernetes)
- Strengths: FOSS, comprehensive, SAML+OIDC, social login
- Strength for KRITIS/Healthcare: Data remains on-premise
- Usage at AWARE7: Docmanager platform, reveal-editor
SSO Security Risks
1. Single Point of Failure / Blast Radius
- IdP compromised = all apps compromised!
- Security strategy: IdP is the most critical system to protect
Risk Mitigation:
- Protect the IdP itself with strong MFA (FIDO2!)
- Privileged IdP admins: Dedicated admin workstations
- PIM for IdP admin roles (just-in-time, time-limited)
2. Session Token Hijacking
- SSO tokens in cookies or URLs can be stolen
- AiTM Phishing (Adversary-in-the-Middle):
- Evilginx, Modlishka: Transparent proxy between user and IdP
- Phishing site routes traffic through it – steals session cookie!
- MFA click does NOT protect (session stolen after MFA!)
Protection against AiTM:
- FIDO2/Passkeys: Token is domain-bound (cannot be stolen!)
- Conditional Access: Limit session lifetime (1–8 hours)
- Token Binding: Bind session to TLS connection (Entra ID)
- Continuous Access Evaluation (CAE): Real-time risk assessment
3. SAML Attacks
XML Signature Wrapping (XSW):
- Attacker copies legitimate assertion + inserts own assertion
- Parser processes incorrect assertion if implementation is flawed
IdP-initiated SSO Abuse:
- IdP sends unsolicited SAML assertion
- No nonce/RequestID verification = replay attack possible
4. OAuth 2.0 / OIDC Vulnerabilities
State Parameter CSRF:
- Missing/invalid state parameter
- CSRF attack: User logs in with attacker’s account!
Redirect URI Manipulation:
- Loose matching: redirect_uri=https://evil.com/cb
- Token is sent to attacker’s server!
JWT Vulnerabilities:
- alg=none: Signature is not verified
- RS256→HS256: Key confusion attack
5. SSO Provisioning Risks
- JIT Provisioning: New user is automatically created
- Problem: Incorrect attribute mapping → wrong roles!
- Example: Email domain matching grants admin rights to the wrong user
SSO Implementation Best Practices
Conditional Access (Entra ID)
Policy Example - All Admin Logins → MFA + Compliant Device Required:
- User Assignment: All users
- Cloud Apps: All cloud apps
- Conditions: Locations: All except trusted IPs; Device Platforms: All
- Access Control: Grant: MFA required AND Compliant Device
- Session: Sign-in Frequency: 1 day; Persistent browser session: No
High-privileged accounts:
- User Assignment: All Global Admins
- Access Control: FIDO2-only (no SMS/TOTP!)
- Session: 4-hour session limits
Token Lifetime Policies
# Entra ID PowerShell:
New-AzureADPolicy -Type TokenLifetimePolicy -Definition @('
{
"TokenLifetimePolicy": {
"Version": 1,
"AccessTokenLifetime": "01:00:00",
"MaxInactiveTime": "30.00:00:00"
}
}
') -DisplayName "ShortTokenLifetime" -IsOrganizationDefault $true
App Registration Hygiene
# Audit: Which apps have SSO access?
Get-AzureADServicePrincipal -All $true |
Where-Object {$_.Tags -contains "WindowsAzureActiveDirectoryIntegratedApp"} |
Select-Object DisplayName, AppId, ReplyUrls
# Review: unused apps, overprivileged scopes
# Graph API Consent: "User.ReadAll" - no regular user should have this!
SCIM Provisioning (automatic user creation)
- SCIM 2.0: Standard for user provisioning between IdP and app
- Entra ID → Salesforce/GitHub/Slack via SCIM
- Advantage: Automatic offboarding (immediate user deactivation!)
- Configuration: Carefully check attribute mapping!
Keycloak Hardening
# keycloak.conf security settings:
https-protocols=TLSv1.3
https-cipher-suites=TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256
http-enabled=false # No HTTP!
Brute-Force Protection (realm settings → Security Defenses):
- Max Login Failures: 5
- Wait Increment: 30s
- Max Wait: 900s (15 minutes)
- Failure Reset Time: 720 (12 hours)
Monitoring
// Entra ID Sign-in Logs → Sentinel:
SigninLogs
| where ResultType != 0 // Failed logins
| where UserPrincipalName !endswith "@serviceprincipal"
| summarize FailedLogins = count() by UserPrincipalName, IPAddress, bin(TimeGenerated, 1h)
| where FailedLogins > 10 // Brute force!
| order by FailedLogins desc