Threat Modeling for SSO/OAuth/OIDC

Overview

Threat modeling for Single Sign-On (SSO), OAuth, and OpenID Connect (OIDC) is a structured approach to identifying, assessing, and mitigating security risks associated with authentication and authorization protocols. It helps organizations understand potential attack vectors and design secure identity and access management systems that leverage these widely adopted standards.

Primary Objectives

• Enable consistent identification and mitigation of security threats specific to SSO, OAuth, and OIDC implementations
• Benefit security architects, developers, auditors, and risk management teams by providing clear risk insights and mitigation strategies
• Support informed decision-making and accountability through documented threat scenarios and control requirements

Scope & Applicability

• Applicable to organizations of all sizes and industries implementing SSO, OAuth, or OIDC for identity federation and delegated access
• Covers security domains including authentication flows, token management, client registration, and user consent; excludes broader network or infrastructure security unless directly impacting these protocols
• Requires foundational governance such as defined identity and access policies, asset inventories of identity providers and relying parties, and data classification related to authentication tokens and user credentials

Core Structure

• Key components include threat categories (e.g., token theft, replay attacks), protocol-specific controls (e.g., redirect URI validation), and mitigation requirements (e.g., use of PKCE)
• Organized by protocol phases: initiation, authorization, token issuance, and token usage, progressing from principles to policies, controls, and verification tests
• Terminology aligns with OAuth 2.0 and OIDC specifications, with mapping anchors to common security control frameworks such as NIST SP 800-63 and OWASP ASVS

How It Is Used

• Adopted through phased rollouts starting with pilot applications to validate threat models and controls before enterprise-wide implementation
• Assessment workflows include threat identification workshops, gap analyses against protocol best practices, and security audits focusing on token handling and client authentication
• Integrated into engineering processes via design reviews, security gates in the software development lifecycle (SDLC), and mapping identified threats to backlog items for remediation

Implementation Artifacts

• Derived policies and procedures addressing secure OAuth/OIDC client registration, token lifecycle management, and incident response for authentication failures
• Control libraries referencing protocol-specific requirements and their mappings to standards such as ISO/IEC 27001 and SOC 2 criteria
• Evidence artifacts including configuration files, access logs, security testing reports, and documented threat model diagrams

Measurement & Maturity

• Key performance indicators include control coverage of identified threats, frequency of security testing, and incident response times related to authentication issues
• Maturity scoring evaluates capabilities from basic awareness of protocol risks to advanced continuous monitoring and automated threat mitigation
• Common baselines define minimum viable controls such as enforcing HTTPS and validating redirect URIs, with advanced levels incorporating adaptive authentication and anomaly detection

Common Pitfalls

• Focusing on checklist compliance without aligning controls to actual protocol-specific risks
• Over-scoping threat models to include unrelated systems or under-scoping by ignoring emerging attack vectors like token replay or phishing
• Lack of ownership for controls, insufficient evidence collection, and outdated documentation leading to gaps in security posture

Integration & Mapping

• Maps to identity and access management frameworks and standards such as NIST SP 800-63, OAuth 2.0 Security Best Current Practice, and OWASP API Security Top 10
• Integrates with governance, risk, and compliance (GRC) systems, security operations centers (SOC), incident response (IR) processes, and SDLC security gates
• Tooling considerations include use of automated control testing platforms, threat modeling software, and identity management solutions supporting protocol compliance

When Not to Use It

• When organizational use of SSO/OAuth/OIDC is minimal or non-existent, making the threat modeling effort disproportionate to risk
• In environments requiring lightweight or incremental security assessments where full protocol-specific threat modeling is too resource-intensive

Standards & References

• Primary references include OAuth 2.0 Authorization Framework (RFC 6749), OpenID Connect Core 1.0 specification, and OAuth 2.0 Security Best Current Practice
• Companion documents such as OWASP OAuth Security Cheat Sheet and NIST SP 800-63 Digital Identity Guidelines provide implementation guidance and mappings