# Cloud Identity Security
Cloud identity security is the discipline of protecting the identity platforms, authentication mechanisms, and access controls that govern access to cloud applications and infrastructure. In a cloud-first environment, identity is the perimeter: users access applications from any location, any device, and any network, and the identity provider's authentication decision is the control that determines whether the access is permitted.
Cloud identity platforms (Microsoft Entra ID, Okta, Google Workspace, Ping Identity, OneLogin) serve as the centralized authentication and authorization authority for cloud applications. When a user logs into Salesforce, Microsoft 365, Slack, or AWS, the authentication request flows through the identity provider. The identity provider verifies the user's credentials, evaluates conditional access policies (device compliance, location, risk level), and issues a token that grants access. Compromising the identity provider provides access to every application federated through it.
This centralization creates both efficiency and concentrated risk. Efficiency: one authentication, one MFA prompt, one set of conditional access policies governs access to every cloud application. Risk: one compromised identity provider equals compromised access to every cloud application. The SolarWinds compromise (APT29 forging SAML tokens to access cloud email) demonstrated that attacking the identity federation layer bypasses every application-level control.
Identity Provider (IdP). The authoritative source for user identities and authentication. Microsoft Entra ID (formerly Azure AD) is the most widely deployed enterprise cloud IdP, serving as the identity authority for Microsoft 365 and hundreds of integrated SaaS applications. Okta, Google Workspace, and Ping Identity serve the same function for organizations using those platforms.
Federation protocols. SAML 2.0 and OIDC (OpenID Connect) enable single sign-on (SSO) between the identity provider and relying applications. The IdP authenticates the user and issues a token (SAML assertion or OIDC token) that the application trusts. The application does not verify the user's credentials directly. It trusts the IdP's assertion that the user is authenticated.
This trust relationship is the architectural vulnerability. If an attacker can forge tokens that the application trusts (Golden SAML), compromise the IdP's signing keys, or steal valid tokens from the user's browser, they bypass every application-level authentication control. The applications trust the token. The token is the proof. Forged or stolen proof grants access.
Hybrid identity. Most enterprise environments operate hybrid identity: on-premises Active Directory synchronized to Entra ID through Entra Connect (formerly Azure AD Connect). Entra Connect synchronizes user accounts, group memberships, and password hashes between the two environments. This synchronization creates a bridge: compromising on-premises AD can provide the material needed to forge cloud tokens (Golden SAML requires the ADFS token-signing certificate, which is obtainable from a compromised on-premises environment).
Token theft. The attacker steals a valid authentication token (OAuth access token, session cookie, SAML assertion) from the user's browser, endpoint, or network traffic. The stolen token provides authenticated access to every application the token is valid for, without re-authentication. Token theft bypasses MFA because the MFA challenge was already satisfied when the token was originally issued.
Adversary-in-the-Middle (AiTM) attacks are the primary token theft technique: the attacker positions a proxy between the user and the legitimate login page. The user authenticates normally (including MFA). The proxy captures the session cookie or token issued after successful authentication. The attacker replays the captured token to access the application as the authenticated user.
Defense: phishing-resistant MFA (FIDO2/WebAuthn, which binds the authentication to the legitimate domain and cannot be proxied), token binding (binding tokens to the device that requested them), continuous access evaluation (revoking tokens when risk conditions change), and short token lifetimes (reducing the window during which a stolen token is valid).
MFA fatigue (push bombing). The attacker obtains the user's password (through phishing, credential stuffing, or breach databases) and triggers repeated MFA push notifications to the user's authenticator app. Fatigued or confused, the user eventually approves one of the push notifications, granting the attacker access. The Uber breach (September 2022) used this technique: an attacker social-engineered a contractor into approving an MFA push after repeated prompts.
Defense: number matching (the user must enter a number displayed on the login screen into the authenticator app, proving they are looking at both screens simultaneously), additional context in push notifications (displaying the application name, location, and device), and phishing-resistant MFA (which eliminates push notifications entirely).
OAuth application abuse. The attacker registers a malicious OAuth application (or compromises a legitimate one) and tricks users into granting it permissions to their cloud resources. A malicious OAuth app with "read all mail" and "read all files" permissions provides persistent, token-based access to the user's email and file storage without requiring the user's credentials. OAuth apps persist independently of the user's password: changing the password does not revoke the app's access.
The Midnight Blizzard (APT29) campaign against Microsoft (disclosed January 2024) used OAuth application abuse to gain persistent access to Microsoft's own corporate environment. The technique is effective against organizations that do not restrict OAuth application registration or monitor application consent.
Defense: restrict OAuth application consent (require admin approval for applications requesting high-privilege permissions), monitor OAuth application registrations and consent events, conduct periodic OAuth application audits (identify and remove unused or suspicious applications), and block risky applications through conditional access.
Golden SAML. The attacker obtains the ADFS/Entra Connect token-signing certificate (from a compromised on-premises environment) and forges SAML assertions for any user without authenticating. Golden SAML provides persistent, undetectable access to every SAML-federated application because the forged token is cryptographically valid (signed with the legitimate certificate).
Defense: protect the token-signing certificate (store in HSM, restrict access to the ADFS server), monitor for anomalous SAML token characteristics (tokens with unusual lifetimes, tokens for users who did not authenticate, tokens from unexpected IP addresses), and migrate to cloud-native authentication (eliminating ADFS and the on-premises token-signing certificate from the attack surface).
Identity provider compromise. Direct compromise of the IdP's administrative interface or infrastructure. An attacker with IdP admin access can create backdoor accounts, modify conditional access policies, disable MFA requirements, and grant themselves access to any federated application. IdP admin compromise is the cloud equivalent of on-premises domain admin compromise.
Defense: protect IdP admin accounts with the strongest available authentication (FIDO2 hardware keys, not push MFA), restrict the number of IdP administrators to the operational minimum, monitor all IdP administrative actions, and implement PIM (Privileged Identity Management) for just-in-time IdP admin elevation.
Conditional access policies. The primary cloud identity security control. Conditional access evaluates context (user identity, device compliance, location, application, risk level) and enforces access decisions (grant, block, require MFA, require compliant device, restrict session).
Essential conditional access policies: require MFA for all users (baseline). Require phishing-resistant MFA for administrative accounts. Block access from non-compliant devices. Block access from countries where the organization does not operate. Require device compliance for access to sensitive applications. Enforce session timeout for high-risk applications.
Continuous Access Evaluation (CAE). Microsoft Entra's CAE enables near-real-time enforcement of policy changes. Without CAE, an access token is valid for its full lifetime (typically 1 hour) even if the user's risk level changes or their account is disabled. With CAE, critical events (account disabled, password changed, high-risk sign-in detected, location change) trigger immediate token revocation. CAE closes the gap between detection and enforcement.
Identity threat detection. Entra ID Protection, Okta ThreatInsight, and third-party ITDR (Identity Threat Detection and Response) platforms detect identity-specific threats: impossible travel (logins from geographically distant locations within a short timeframe), anomalous token activity, password spray attempts, suspicious OAuth application consent, and AiTM indicators. Identity threat detection integrates with SIEM for cross-domain correlation.
Application governance. Control which applications can be used, which permissions they can request, and how application consent is managed. Block unverified applications. Require admin consent for high-privilege permissions. Audit existing application permissions quarterly. Remove applications that are no longer in use.
In cloud environments, there is no network perimeter to protect. Users access applications from anywhere. The identity provider's authentication decision is the only control that stands between the user (or attacker) and the application. Every identity security weakness (weak MFA, permissive conditional access, unmonitored OAuth applications) is a perimeter weakness.
Microsoft reports that identity-based attacks increased over 300% in 2023. Token theft through AiTM attacks has become the dominant credential attack technique, surpassing traditional credential phishing. OAuth application abuse is increasing as attackers recognize that application permissions persist independently of password changes. The threat landscape has shifted from "steal the password" to "steal the token" and "abuse the application."
Cloud identity controls satisfy compliance requirements across multiple frameworks. PCI DSS Requirement 8 (authentication). HIPAA access control requirements. NIST 800-171 AC-2 (account management) and IA-2 (identification and authentication). SOC 2 CC6.1 (logical access). ISO 27001 A.8.5 (secure authentication). Every framework requires authentication controls. In cloud environments, those controls are implemented at the identity provider.
Cloud identity security sits in the IAT (Identity Access and Trust) domain of the Planetary Defense Model. IAT is civilization: who is in the environment, what can they access, and how trust is established.
CDA's Zero Possession Architecture (ZPA) methodology applies directly to cloud identity. "Trust nothing. Possess nothing. Verify everything." Every cloud access request is verified through the identity provider (trust nothing by default). Tokens are short-lived and continuously evaluated (possess nothing permanently). Device compliance, user risk, and application context are evaluated on every request (verify everything).
IAT-B01 (Zero Trust Architecture Design, 40 estimated hours) includes cloud identity architecture as a core component: IdP hardening, conditional access policy design, phishing-resistant MFA deployment, OAuth application governance, CAE configuration, and hybrid identity security (Entra Connect hardening, ADFS migration planning).
CDA approaches cloud identity with one priority: phishing-resistant MFA for every administrative account, no exceptions. An IdP admin account protected by push-notification MFA is vulnerable to MFA fatigue and AiTM attacks. An IdP admin account protected by a FIDO2 hardware key is resistant to both. The IdP admin accounts are the keys to the kingdom. They receive the strongest authentication available.
Word count: 1,972