Web Login & Identity Federation: Deep Dive into SAML, OAuth/OIDC, MFA & Secure Design

Modern web applications offload user authentication to a centralized Identity Provider (IdP) such as Ping Identity(PingFederate / PingOne Advanced Identity Cloud) or Microsoft Entra ID (Azure AD). This federated login model lets multiple applications trust a single identity hub for verifying user credentials, enabling Single Sign-On (SSO): users sign in once and gain access to multiple systems. The business application (the Service Provider or OAuth Client) never sees the user’s password — it receives only security tokens from the IdP. In SAML, the application trusts the IdP’s signed assertion and grants access without ever handling the user’s credentials directly. This design improves security and user experience: credentials are managed in one hardened service, and users avoid repeating logins across apps.

Both SAML 2.0 and OAuth 2.0 / OpenID Connect (OIDC) are widely-used standards enabling federation and SSO. SAML uses XML-based assertions and works best in browser-based enterprise applications, while OIDC uses lightweight JSON tokens and fits modern web, mobile, and API-driven architectures. Below is a comprehensive technical analysis of each, including how to incorporate multi-factor authentication (MFA), secure password handling, token design & validation, API security, and threat mitigations — all oriented toward designing a custom identity solution with the robustness of a commercial IdP.

---

1. SAML 2.0 Web SSO Flow (Federated Login via SAML)

Security Assertion Markup Language (SAML) 2.0 is an open standard for exchanging authorization and authentication information. The Web Browser SAML/SSO Profile with Redirect/POST bindings is one of the most common SSO implementations. SAML became the enterprise standard for SSO in the early 2000s because organizations wanted users to log in once and access dozens of internal applications without repeatedly typing passwords. Below is a step-by-step SP-Initiated SAML login (using Ping Identity or Azure AD as the IdP):

• Step 1: User Accesses Protected Application (SP)

  The user tries to access an application (Service Provider) without a session. The SP detects no active session and generates a SAML AuthnRequest message. This request is typically sent via an HTTP redirect to the IdP’s SSO URL (compressed and URL-encoded) or via an auto-submitted form POST. The user’s browser is redirected to the IdP. The AuthnRequest must contain an ID (a string uniquely identifying the request) and an SP identifier.

• Step 2: Identity Provider Authenticates the User

  The IdP (PingFederate, Azure Entra ID, etc.) receives the AuthnRequest and identifies the requesting SP. It then authenticates the user using its own policies. The user enters credentials on the IdP’s login page served over HTTPS. TLS 1.2 (or higher) guarantees message confidentiality and integrity at the transport layer, countering eavesdropping, theft of user authentication information, theft of the bearer token, message deletion, message modification, and man-in-the-middle attacks. The IdP checks credentials against its user directory (e.g. Active Directory, Ping Directory, or an internal store). The user’s password is never shared with the SP. If policy requires it, the IdP may also enforce MFA at this stage before proceeding.

• Step 3: IdP Issues a SAML Assertion

  Upon successful authentication, the IdP generates a SAML Response containing a SAML Assertion — an XML document with the user’s identity information (subject name/ID), authentication timestamp, conditions for validity, and optional attributes (e.g. roles, email). The IdP digitally signs the assertion (or entire response) with its private key using a certified key, which helps guarantee message integrity and authentication and counters man-in-the-middle (6.4.2), forged assertion (6.4.3), and message modification (7.1.1.7) attacks. Assertions may also be encrypted via XMLEnc to prevent disclosure of sensitive attributes post-transportation, countering theft of user authentication information (7.1.1.2). The response includes a unique ID and an InResponseTo field binding it to the original AuthnRequest — a safeguard whose absence famously left Google’s SSO vulnerable to a man-in-the-middle attack from a malicious SP. The IdP then redirects the user’s browser back to the SP’s Assertion Consumer Service (ACS) URL, typically via an auto-POST form.

• Step 4: Service Provider Validates & Grants Access

  The SP’s ACS endpoint receives the SAML Response and validates it against the IdP’s public signing certificate (exchanged via SAML metadata beforehand). It checks: (a) the XML signature is valid and from the trusted IdP; (b) the assertion’s conditions — NotBefore/NotOnOrAfter window, AudienceRestriction matching the SP’s identifier; (c) the InResponseTo matches the original request ID. Once verified, the assertion proves the user’s identity. The SP creates a local session and authorizes access. The user is now logged in without ever directly providing credentials to the SP.

SAML Assertion Internals

A SAML 2.0 assertion issued by the IdP contains several key elements:

• Authentication Statement: Confirms when and how the user was authenticated (e.g., “via password plus OTP”). May include an AuthnContextClassRef indicating if MFA was used.
• Subject & Identifiers: The user’s identity (NameID, e.g. email format), plus a SubjectConfirmation element ensuring the token was delivered to the intended SP.
• Attribute Statements: Optional user profile data (e.g. name, role, group) attested by the IdP, which the SP can use for authorization decisions.
• Conditions: Validity constraints — a NotBefore/NotOnOrAfter window (often just minutes) and AudienceRestrictionspecifying the SP’s identifier. Short lifetimes limit the impact of a stolen assertion — a key defense recommended by OWASP.
• Signature: The IdP’s digital signature covering the assertion using RSA or ECDSA via XML Digital Signature standards. The SP must reject any unsigned or tampered SAML response.
• Encryption (Optional): The IdP can encrypt the assertion with the SP’s public key via XMLEnc so only that specific SP can decrypt and read it.

IdP-Initiated SSO

In an IdP-initiated flow, the user starts at the IdP portal and launches an application directly — the IdP creates an assertion without a prior AuthnRequest. Despite being convenient, this flow is considered less controlled; OWASP notes IdP-initiated SSO is supported primarily for backward compatibility (notably with SAML 1.1) and is susceptible to replay attacks (6.1.2). If it must be enabled, additional validation per SAML Profiles section 4.1.5 should be applied. SP-initiated SSO with strict InResponseTo validation is the preferred secure approach.

Session Management in SAML

After SAML login, sessions exist at two layers:

• IdP Session: The IdP sets a secure cookie so the user remains authenticated. This enables SSO: if the user later accesses another SAML-enabled app, the IdP can silently re-authenticate them (no password needed) until this IdP session expires.
• SP Session: The application creates its own session (e.g. an HTTP-only session cookie). The SAML assertion is typically consumed once at login; after that, the app trusts its own session mechanism.

Where SAML Remains the Right Choice

SAML remains appropriate for enterprise workforce SSO into HR systems, CRM platforms, and internal portals; B2B integrations where both parties operate within structured enterprise environments; government and regulated industries with long-standing SAML-based infrastructure; and legacy applications built before modern token-based protocols existed. In one enterprise environment, SAML is the only SSO integration currently offered to B2B customers, though introduction of OIDC is recommended for those SAML customers as part of the overall integration design.

---

2. OAuth 2.0 & OpenID Connect (OIDC) Login Flow

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. Where OAuth handles authorization (granting limited access to resources), OIDC adds authentication, giving applications a standardized way to verify who a user is. Instead of XML assertions, OIDC uses lightweight JSON Web Tokens (JWTs) that are compact, easy to validate across languages and frameworks, and travel natively across APIs, mobile apps, and microservices.

A concrete example: the Staples.com consumer application was onboarded with CIAM using OpenID Connect protocol and PKCE for user authentication, integrating with Ping Advanced Identity Cloud. Below is the standard OIDC Authorization Code flow with PKCE:

OIDC Token Internals

The ID Token in OIDC is a JSON Web Token — three Base64Url-encoded parts (header, payload, signature). IdPs publish their JWT signing keys in a JWKS (JSON Web Key Set) endpoint accessible via the .well-known/openid-configurationdiscovery document. The client fetches the key matching the token’s kid (Key ID) to verify the signature. Standard claims include:

• iss (issuer): Identifier of the IdP — the client must verify this matches the expected IdP.
• aud (audience): The client’s ID — the token is intended for this specific application.
• exp and iat: Expiration and issued-at timestamps. Tokens should have short lifetimes.
• User claims: sub (subject ID), name, email, etc.
• acr or amr: Authentication Context Class Reference or Authentication Methods References — indicating what measures were used (e.g., password, OTP). In the Ping implementation, specific authentication journeys can be assigned to OAuth clients by mapping acr_values to authentication journeys in the OpenID Connect configuration.

Access Tokens can be JWTs (validated locally by checking signature, audience, expiry, and scopes) or opaque tokens (validated by calling the IdP’s introspection endpoint). The platform should support management of claims-based authorization, such that claims and scopes can be included in secure tokens for verification by other system components.

Where OIDC Fits Best

OIDC is ideal for modern web applications, SPAs, and mobile apps; API-driven architectures where services need to validate identity across calls; consumer-facing products where social login is expected; cloud-native and microservices environments; and any new system being built today. OIDC also gives users built-in consent flows, letting them control which attributes they share — a feature requiring extensive custom development in SAML.

---

3. SAML vs. OIDC: Comparison

Aspect	SAML 2.0	OIDC (OAuth 2.0 + ID)
Released	2002	2014
Data Format	XML	JSON (JWT)
Built On	Independent standard	OAuth 2.0
Best For	Browser-based enterprise SSO	Web apps, mobile, APIs, SPAs
Token Type	SAML Assertion (signed XML)	ID Token + Access Token (JWT)
Integration Complexity	Higher — XML, certificates, metadata	Lower — REST APIs, standard libraries
Mobile Support	Limited	Native
User Consent	Manual to configure	Built in
Adoption Trend	Dominant in legacy enterprise	Growing in modern architectures
Login Flow	Browser redirects + auto-POST form carrying a SAML Response	Browser redirects to /authorize, then server-to-server token exchange (Auth Code flow)
API Compatibility	Not designed for direct API calls; adapting to mobile/API requires complex workarounds	Tokens travel naturally through HTTP headers and work natively with mobile clients and APIs
Security Risk Profile	Complexity makes it more prone to misconfiguration	Inherits OAuth 2.0’s documented threat model; common attack surfaces are better defined and easier to address

Key Tradeoff: SAML’s XML verbosity creates more processing overhead and is harder to diagnose when misconfigured, while OIDC’s JSON/JWT format is significantly faster to process — in high-throughput environments with thousands of API calls per minute, that difference is measurable. However, replacing functioning SAML integrations carries real cost and risk. The practical recommendation: if SAML is working in your environment, default new systems to OIDC going forward while maintaining SAML for existing integrations.

Ping Identity vs. Azure Entra ID — Conceptual Differences

Both platforms implement SAML, OAuth2, and OIDC. Key differences lie in deployment model and ecosystem:

• Azure Entra ID (formerly Azure AD) is a cloud-based multi-tenant IdP and directory tightly integrated with the Microsoft/Office 365 ecosystem. Organizations use Azure AD as the central corporate identity source. It offers built-in Conditional Access, identity protection, and device integration. One enterprise initiative retired on-premises SiteMinder infrastructure and migrated all workforce SSO integrations to Azure AD, achieving $2.2M in cost avoidance along with streamlined user lifecycle provisioning, robust conditional access, entitlement management, and advanced Identity Governance capabilities. Azure AD’s architecture framework recommends using managed identities for resource-to-resource authentication, preferring passwordless methods, and enabling conditional access based on key security attributes especially for high-privilege accounts.
• Ping Identity offers both on-premises (PingFederate) and cloud solutions (PingOne Advanced Identity Cloud). Ping provides greater deployment flexibility — enterprises can run their own IdP with custom integration, or use Ping’s cloud for customer identity management (CIAM) separately from corporate IT systems. In the same enterprise, Ping Identity’s cloud IDaaS was selected for customer identity modernization, migrating away from on-premises CA Broadcom infrastructure to a cloud-based IDaaS service via Ping Identity. Ping’s strength is in customizable authentication “journeys” (with 12 journeys anticipated for one integration) and integration kits that can be tailored to unique use cases. The PingOne MFA Integration Kit allows PingFederate to use the PingOne MFA service, integrating MFA into SAML, WS-Fed, OAuth, and OIDC flows in a seamless way leveraging one configuration for all use cases.

From a developer’s perspective, both platforms expose standard endpoints (SAML metadata, OAuth2/OIDC endpoints) that custom applications integrate with in the same standard way — the differences lie in management, deployment flexibility, and ancillary features.

---

4. Multi-Factor Authentication (MFA) Integration

MFA ensures that digital users are who they say they are by requiring at least two pieces of evidence from different categories: something they know, something they have, or something they are.

How MFA Fits into Authentication Flows

In a federated login, MFA is handled by the Identity Provider, not by each individual application. The IdP’s authentication policy decides when to require MFA:

• Triggering Conditions: The IdP can enforce MFA always, or conditionally (e.g., based on risk level, device posture, user group, network location). Azure AD’s Conditional Access enables risk-based MFA. Ping’s authentication journeys allow rule-based step-up. A custom IdP should have a policy engine to determine when extra factors are needed.
• Timing in the Flow: If MFA is required, the IdP prompts right after the primary password is verified (Step 2 in both SAML and OIDC flows). The IdP pauses to perform the second factor before issuing any tokens. In Ping’s implementation, MFA preference and verification status are tracked as custom user attributes: FrIndexedInteger1(tagged for Preferred MFA, bit-masked) and FrIndexedInteger2 (tagged to Verified MFA, bit-masked).

MFA Methods

Common second factors include:

• TOTP/OTP: One-time passcodes generated by an authenticator app or sent via SMS.
• Push Approval: Notifications sent to a mobile app (e.g., PingID, Microsoft Authenticator) requiring user confirmation.
• FIDO2/WebAuthn: Hardware security keys or platform biometric authenticators. These are phishing-resistantbecause the private key never leaves the device and the login operation is cryptographically bound to the origin.
• Phone Callbacks: Voice call verification.

Ping Identity provides PingID for MFA, which supports web, VPN (via RADIUS protocol), Windows login, and Mac login as second-factor authentication. In the Staples.com integration, 1Kosmos serves as the MFA partner, integrated via API into Ping Identity’s authentication journeys.

MFA State Management

Implementing MFA requires the IdP to handle a multi-step interaction. The IdP must maintain the user’s partial authentication state between steps (e.g., password verified, awaiting OTP). In Ping’s implementation, this is managed through authentication journeys — configurable workflow trees that chain authentication nodes (username/password ? MFA challenge ? success). Environment variables and secrets are used across scripts and authentication journeys.

Mitigating MFA Fatigue

A critical concern: MFA fatigue attacks where attackers bombard users with push notifications hoping for an inadvertent approval. Microsoft addressed this by enforcing number matching in Microsoft Authenticator push notifications as of May 8, 2023 — users must type a number displayed on the login screen into their authenticator app rather than simply tapping “Approve”. For custom builds, implement interactive verification that cannot be easily “fatigued” — e.g., requiring the user to enter a displayed code, or showing additional context (app name, geographic location) in the approval prompt.

MFA Signals in Tokens

• SAML: The <AuthnContextClassRef> in the assertion can indicate the authentication method used (e.g., urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken for OTP).
• OIDC: The acr (Authentication Context Class Reference) and amr (Authentication Methods Reference) claims in the ID token indicate whether MFA was completed and which methods were used.

Applications that need to ensure a user completed MFA should configure the IdP to require it and validate these token claims.

---

5. Secure Password Handling & Server-Side Processing

When using federated IdPs, web applications do not handle raw passwords, but the IdP must handle them for password-based logins. Whether operating a custom IdP or using Ping/Entra, secure password management is essential.

Password Transmission: TLS in Transit

All login pages and API calls must use HTTPS. TLS 1.2 (or higher) is the most common solution to guarantee message confidentiality and integrity at the transport layer, countering eavesdropping (7.1.1.1), theft of user authentication information (7.1.1.2), theft of the bearer token (7.1.1.3), message deletion (7.1.1.6), message modification (7.1.1.7), and man-in-the-middle (7.1.1.8) attacks.

Password Storage: Hashing, Salting, and KDFs

Passwords must never be stored in plaintext or reversible encryption. Hashing is a one-way function — it is impossible to “decrypt” a hash and obtain the original plaintext value, making it the most appropriate approach for password validation. OWASP’s specific recommendations for password hashing algorithms (in priority order):

Algorithm	Recommended Configuration	Notes
Argon2id(preferred)	Minimum 19 MiB of memory, iteration count of 2, and 1 degree of parallelism	Memory-hard, best defense against GPU attacks
scrypt	Minimum CPU/memory cost parameter of 2^17, minimum block size of 8 (1024 bytes), parallelization parameter of 1	Alternative when Argon2id unavailable
bcrypt(legacy)	Work factor of 10 or more, password limit of 72 bytes	Widely supported in legacy systems
PBKDF2(FIPS-140)	Work factor of 600,000 or more, internal hash function of HMAC-SHA-256	Required for FIPS-140 compliance

Salting is critical: a unique, randomly generated string added to each password before hashing. Since the salt is unique for every user, an attacker must crack hashes one at a time using the respective salt rather than pre-computing a hash once. This makes cracking large numbers of hashes significantly harder, and also means it’s impossible to determine whether two users have the same password without cracking the hashes. Modern algorithms (Argon2id, bcrypt, PBKDF2) handle salt generation internally.

Peppering provides additional defense in depth — a shared secret stored separately from the password database (ideally in HSMs or secrets vaults), preventing an attacker from cracking hashes even if they obtain the database. However, a pepper compromise requires forcing all protected users to reset passwords.

Work Factor Tuning: The work factor makes hashing more computationally expensive, reducing the speed at which an attacker can crack hashes. As a general rule, calculating a hash should take less than one second to balance security and performance — if too high, it could enable denial-of-service via excessive CPU exhaustion from login attempts.

Real-World Password Handling in Enterprise Migration

In one enterprise’s Ping Identity migration, a specific milestone was planned to “design solution to standardize password hashing from four legacy methods”, involving conversion and reconciliation of over 1 million user accountsacross master accounts from Ping Directory to Ping AIC in production environments. The password hashing conversion approach was identified and under testing as of the most recent reporting.

Password Policy Example (Ping AIC Implementation)

The Ping AIC deployment enforces the following password policy:

Field	Min Length	Max Length	Requirements
Password	8	20	8 characters minimum, case sensitive, no spaces. Must contain 3 of 4 criteria: uppercase letter, lowercase letter, number, special character
Email	N/A	256	Must have local part, @ symbol, and valid domain
First name	1	15	Letters, numbers, spaces allowed
Last name	1	20	Letters, numbers, spaces allowed
Phone	1	10	Exactly 10 digits, area code first digit 2-9, central office first digit 2-9

Account lockout is configured to lock the user after 10 invalid attempts. Accounts can be unlocked via self-service (Forgot Password journey) or by calling customer care.

Credential Protection Beyond Hashing

• Compromised credential detection: The Ping deployment integrates with SpyCloud to detect compromised credentials and stop logins.
• Bot mitigation: NuData CAPTCHA (transitioning to reCAPTCHA) protects login endpoints from fraud and automated abuse.
• Passwordless options: Both Azure and Ping support passwordless authentication (FIDO2 keys, magic links). Azure AD’s architecture framework recommends preferring passwordless methods or opting for modern password methods.

---

6. Token Security: Signing, Encryption, and Key Management

Token Signing & Validation

All tokens must be signed by the Identity Provider:

• SAML: A digitally signed message with a certified key guarantees message integrity and authentication. The SP uses the IdP’s public signing certificate (from SAML metadata) to verify the XML signature. Use RSA with at least 2048-bit keys and SHA-256 or better.
• OIDC/OAuth: ID and Access tokens are JWTs signed via JWS (e.g., RS256). The OIDC discovery document provides the IdP’s JWKS (JSON Web Key Set). The JWT header’s kid claim identifies which key was used.

Token Encryption

• SAML: Assertions may be encrypted via XMLEnc to prevent disclosure of sensitive attributes post-transportation. The IdP uses the SP’s public key from metadata.
• OIDC: JWT supports JWE (JSON Web Encryption) for ID or access tokens, though in practice ID tokens are usually just signed since their contents flow over TLS. Access tokens can be issued as opaque reference tokens if confidentiality of claims is a concern.

Key Management & Rotation

• Protection: Store private keys in secure vaults or HSMs. In the Ping AIC implementation, service accounts are created with minimum necessary scopes, and private keys must be downloaded at creation time as they will not be available again. Before regenerating a key, all dependent integrations that use the key to sign JWTs must be identified and updated with the new key.
• Rotation: Publish new public keys before transitioning. Use the JWT kid header to allow parallel keys. For SAML, metadata can list multiple certificates for overlap during rotation.
• Scope Control: Ping AIC service accounts use granular scopes: fr:am:* for /am/* API endpoints, fr:idm:* for /openidm/* and ESV API endpoints, fr:idc:esv:* for ESV API endpoints, fr:idc:esv:read for read-only ESV access, fr:idc:esv:update for create/update/delete ESV access, and fr:idc:esv:restart for restarting Identity Cloud services. The principle: always choose the minimum number of scopes needed.

Token Lifetime & Refresh

Short-lived tokens are a core defense. Short assertion lifetimes help counter stolen assertions and replay attacks. Access tokens typically expire in 1 hour or less. Refresh tokens enable long-lived sessions without re-login but must be stored securely and revocable. If a token’s validity is questioned, the system should support token introspection (per RFC 7662) where resource servers verify token status with the IdP.

Audit Logging

PingOne Advanced Identity Cloud provides audit and debug logs to help manage tenants. Audit logs investigate user and system behavior; debug logs investigate production issues. Advanced Identity Cloud stores logs for 30 days accessible via the /monitoring/logs endpoint. Log sources include am-access, am-activity, am-authentication, am-config, am-core, am-everything, idm-access, idm-activity, idm-authentication, idm-config, idm-core, idm-everything, idm-recon, and idm-sync — 14 sources total. The deployment also integrates logs with Splunk for operational convenience.

---

7. Securing APIs with OAuth2 Tokens

When an IdP issues access tokens for API access, those tokens must be properly validated by resource servers. A microservices delivery platform must provide the ability to secure authentication identities and issue secure tokens that can be verified by other system components, support management of claims-based authorization (claims and scopes included in tokens for verification), and provide runtime protection from common attack patterns including OWASP Top Ten for web applications and the OWASP API Security Top Ten.

OAuth Scopes and Audience

• Scopes: Define named permissions for each API (e.g., order.read, order.write). Include granted scopes as claims in access tokens. The API must check the token’s scope claim to authorize each request — principle of least privilege.
• Audience Restriction: Each access token must be issued for a specific audience (unique API identifier). APIs must verify the aud claim matches their own identifier. This prevents a confused deputy problem where a token for one service is replayed to another.

Token Validation at the API Layer

For each API call, the resource server validates the access token:

• JWT validation: Verify signature (using IdP’s public key from JWKS), check aud matches the service, exp is in the future, and required scopes/claims are present.
• Opaque token validation: Call the IdP’s introspection endpoint to verify active/inactive status and retrieve associated claims.

Proof-of-Possession & mTLS

Bearer tokens can be enhanced with mutual TLS (mTLS) — requiring the client to present a client certificate when calling the API — or DPoP (Demonstration of Proof-of-Possession) where the token is cryptographically bound to a key held by the client. These techniques ensure a stolen access token alone cannot be used by an attacker. At minimum, prefer short-lived tokens to limit the window of exposure.

API Gateway Integration

APIs are often fronted by a gateway or reverse proxy that handles auth checks. The enterprise architecture references Azure API Management with identity and access management, network security baselines, and secure developer portal access as key practices. The delivery platform may integrate with API gateways to validate that only intentional APIs are accessible and provide API discovery capabilities.

---

8. Internal Architecture Components of an Identity System

Designing a system comparable to Ping or Azure AD requires several interconnected components:

Core Components

Component	Purpose	Implementation Notes
User Directory / Identity Store	Stores user identities, credential hashes, profile data, group/role memberships, and user status	Azure AD is a cloud directory; Ping can integrate with AD, LDAP, or PingDirectory. In a custom solution, use a secured SQL/NoSQL DB or delegate to enterprise AD via LDAP
Authentication Service (IdP Server)	Provides protocol endpoints (/authorize, /token, SAML SSO), validates credentials, enforces policies	Must handle authentication journeys (Ping’s term) or authentication flows. Consider open-source bases like Keycloak rather than coding from scratch
Authorization / Policy Engine	Makes adaptive decisions (risk-based MFA, conditional access, IP restrictions)	Azure AD’s Conditional Access; Ping’s policy rules. Custom IdPs should implement rules based on user attributes, client app, and context
Token Service & Key Management	Issues and signs tokens (SAML assertions, JWTs), manages cryptographic keys	Should run in an isolated environment with HSM key storage. Track key rotation and auditing
MFA Service	Manages second-factor challenges across methods (OTP, push, FIDO2)	Can be built-in or external. Ping uses PingID/1Kosmos; Azure has Microsoft Authenticator. Consider TOTP libraries or WebAuthn for custom builds
Session / Cache Store	Tracks active IdP sessions, used assertion/code IDs (for replay prevention), partial auth state	Fast store (Redis, in-memory cache) for code lifecycle and session tracking
Administration & APIs	Manages client registrations, SP connections, user/group administration, scopes, logs	Ping AIC provides an admin UI plus REST API management for service accounts and configurations
Monitoring & Logging	Audit logs for auth events, token issuance, admin changes; debug logs for production issues	Ping AIC: 30-day log retention via /monitoring/logs endpoint. Integrate with SIEM (e.g., Splunk)

Security Architecture Pillars

A reference enterprise security architecture defines five pillars: (1) Platform Security — securing resources via Azure Key Vault and ACLs; (2) User Authentication Security — Active Directory integrated security with multi-layer SSO (SAML) and MFA; (3) Role-Based Security — fine-grain access to specific data based on metadata; (4) Data Transit Security — encryption at rest and in transit via TLS, server-side encryption, and tokenization; (5) Auditing — logging and audit strategy for security events and alerts generated based on unauthorized access.

High Availability & Scaling

Both Ping and Azure run in multi-server, highly available setups (Azure AD is globally distributed; PingFederate can be deployed in clusters). A custom system should eliminate single points of failure through multiple IdP instances, load-balanced, with shared state (database/Redis) or stateless tokens. SAML XML processing and JWT signing/verification can be CPU-intensive — size servers accordingly.

---

9. Threat Modeling & Mitigations

Threat Matrix

Threat	Attack Description	Key Mitigations
Eavesdropping & MITM	Attacker intercepts passwords or tokens in transit	TLS 1.2+ for all communications; HSTS enforcement; certificate validation; IP filtering where appropriate
Phishing	Fake login pages trick users into entering credentials	Domain-specific branded login pages; phishing-resistant MFA (FIDO2/WebAuthn); MFA number matching to prevent push fatigue; user education
Credential Stuffing / Password Spray	Automated attempts using stolen or common password lists	Account lockout/throttling (e.g., 10 attempts); CAPTCHA/bot detection (reCAPTCHA, NuData); compromised-credential checks (SpyCloud); MFA as a second barrier
Replay Attacks	Capturing and reusing valid assertions or auth codes	SAML assertion unique IDs tracked for one-time use; OAuth auth codes are single-use; short token lifetimes; validate InResponseTo in SAML; OIDC state parameter for CSRF prevention
Forged Assertions / Token Tampering	Attacker modifies or fabricates tokens	Digital signatures on all tokens; strict signature validation; reject unexpected algorithms; guard against XML Signature Wrapping in SAML
CSRF	Tricking user into initiating unwanted login or action	OAuth state parameter binding request-to-response; anti-CSRF tokens on all IdP forms; SameSite cookie attributes
XSS	Injected script steals session or tokens	HTTPOnly cookies for session tokens; Content Security Policy; output encoding; avoid storing tokens in localStorage (prefer secure HTTPOnly cookies or memory-only storage)
Token Theft	Malicious app or malware steals access/refresh tokens	Short-lived access tokens; secure token storage (HTTPOnly cookies, OS secure storage on mobile); DPoP/mTLS for proof-of-possession; easy token revocation by admin or user
Confused Deputy	Token meant for one API is presented to another	Strict audience (aud) validation on all resource servers; per-API audience identifiers
MFA Fatigue	Attacker spams push notifications until user approves	Number matching in push notifications; additional context display (app name, location); anomaly detection on repeated MFA prompts
Golden SAML	Attacker steals IdP signing key to forge arbitrary assertions	HSM-based key storage; key rotation; monitoring for anomalous assertion patterns; restrict access to IdP infrastructure

Detailed Mitigations for Critical Threats

SAML-Specific Security: The OWASP SAML Security Cheat Sheet identifies that the SSO Web Browser Profile is most susceptible to attacks from trusted partners. The AuthnRequest must contain ID and SP; the Response must contain ID, SP, IdP, and a signed assertion ({AA} K-1/IdP). The request ID must be returned in the response (InResponseTo="<requestid>") to guarantee authenticity. Assertions may additionally be encrypted to prevent post-transport disclosure. IP filtering per trusted partner endpoint can help counter stolen assertion (6.4.1) and man-in-the-middle (6.4.2) attacks.

Credential Protection Pipeline: A production-grade implementation integrates multiple defense layers at the login endpoint: SpyCloud nodes for compromised credential detection, 1Kosmos MFA APIs for second-factor challenges, NuData/reCAPTCHA for bot traffic detection, and Akamai edge controls for additional security.

AM Hardening Guidelines: The security control objectives for an IdP platform are to ensure access is authenticated, authorized, and audited. Hardening guidelines include: securing communication with encryption for all data transmissions, protecting network access with HTTPS protocols, turning off services or features not being used, and auditing all events and changes.

---

10. Implementation Guidance for Custom Applications

Design Principles

When building a custom identity system, follow these principles drawn from enterprise practice:

1. Use standards-based protocols. A standards-based architecture delivers modern authentication options and capabilities. Leverage SAML for compatibility with enterprise apps and OIDC/OAuth for modern applications and APIs. Do not invent new auth protocols.
2. Centralize authentication. Applications should delegate auth to the IdP, which issues signed tokens that apps rely on. This eliminates per-app password silos and concentrates security investment in a single hardened service.
3. Never roll your own cryptography. Use well-vetted libraries for XML signature processing, JWT signing/verification, password hashing, and TLS configuration. Standard libraries handle edge cases (constant-time comparison, algorithm validation, key management) that are easy to get wrong.
4. Implement defense in depth. Layer multiple protections: TLS in transit, hashed passwords at rest, MFA at login, signed/encrypted tokens, short lifetimes, scope-limited access, monitoring, and intrusion detection.
5. Plan for migration and evolution. Enterprise migrations (e.g., from SiteMinder to Azure AD or Ping) reveal the importance of standardization — legacy systems may have multiple incompatible password hashing methods requiring consolidation. Design for future algorithm upgrades from the start.

Comparison: Local Password Auth vs. Federated SSO

Aspect	Local Password Authentication	Federated SSO (SAML/OIDC)
Credential Handling	App stores and verifies password hashes directly	App never sees or stores passwords; IdP handles all credential verification
Attack Surface	Each app is a target for credential theft	Credentials concentrated at one hardened IdP; apps have smaller attack surface
MFA	Must be implemented per-app	Centralized at IdP; all apps benefit automatically
User Experience	Users manage separate credentials per app	Single login grants access to multiple apps
Complexity	Simpler for a single app; scales poorly	More initial setup (protocol integration, metadata exchange); scales well across many apps
Standards	Custom implementation	SAML, OIDC, OAuth 2.0 — interoperable with commercial IdPs and SaaS apps
Maintenance	Each app must update auth independently	Security improvements (stronger hashing, new MFA methods) deployed centrally once

Practical Architecture Decisions

If building from scratch: Consider starting with an open-source identity platform (e.g., Keycloak) that provides SAML and OIDC endpoints, user management, MFA plugins, and admin UI out of the box. Customize it to your needs rather than building every component from scratch. This approach gives you the benefit of community-audited security implementations while maintaining flexibility.

If integrating with existing IdPs: Your application only needs to implement the Relying Party (OIDC) or Service Provider (SAML) side — validate tokens/assertions, manage local sessions, and enforce scope-based authorization on APIs. Libraries exist for every major framework (Spring Security, passport.js, MSAL, etc.) that handle protocol mechanics.

Hybrid approach: Many enterprises operate both SAML and OIDC simultaneously through an IdP that brokers both protocols. The challenge is maintaining consistency — when identity flows through two protocols across different systems, audit trails can fragment and session management becomes complicated. Design for this reality by standardizing user identifiers and session management across both protocols.

Key Standards References

For implementation, the authoritative sources are:

• SAML 2.0: OASIS Security Assertion Markup Language specification, SAML Profiles section 4.1.4.1 (AuthnRequest) and 4.1.4.2 (Response), SAML Security Considerations (sections 4.2.1, 4.2.2, 4.3)
• OAuth 2.0: RFC 6749 (framework), RFC 7636 (PKCE), RFC 7662 (introspection), RFC 8252 (native apps)
• OIDC: OpenID Connect Core 1.0
• Password Storage: OWASP Password Storage Cheat Sheet; NIST SP 800-63B (Digital Identity Guidelines)
• SAML Security: OWASP SAML Security Cheat Sheet
• API Security: OWASP API Security Top Ten

---

In summary, a well-designed identity system centralizes authentication at a trusted IdP, uses standards-based protocols (SAML for enterprise federation, OIDC for modern apps and APIs), protects passwords with memory-hard hashing algorithms and TLS, issues cryptographically signed tokens with appropriate scopes and audiences, integrates MFA as a seamless part of the authentication journey, and defends against a comprehensive threat model spanning phishing, replay, credential stuffing, token theft, and more. By following the patterns established by Ping Identity and Azure Entra ID — while grounding every design decision in public standards and proven security practices — a custom-developed solution can achieve comparable security and interoperability.