Identity is the new perimeter. SAML 2.0, OpenID Connect, and OAuth 2.0 enable organisations to federate their corporate identity into cloud platforms — eliminating the need for per-service passwords while centralising authentication and audit.
Sign in to mark this article as read and track your progress.
The phrase "identity is the new perimeter" has become standard in cloud security for a specific reason: in a cloud environment, there is no physical boundary around resources. An S3 bucket, a Lambda function, or an EC2 instance can be accessed from any location. The only barrier between an attacker and those resources is authentication and authorisation — which are both identity functions.
The 2022 Uber breach began with an attacker purchasing an Uber contractor's VPN credentials on the dark web and then exploiting weak MFA (push notification fatigue) to gain access. No network firewall was involved; the entire attack surface was the identity layer.
| Term | Definition | Cloud Example |
|---|---|---|
| Authentication (AuthN) | Proving who you are | MFA challenge when logging into AWS Console |
| Authorisation (AuthZ) | Proving what you are allowed to do | IAM policy allowing s3:GetObject on a specific bucket |
| Identity Provider (IdP) | The system that stores and verifies identities | Azure Entra ID, Okta, JumpCloud |
| Service Provider (SP) | The application that delegates authentication to the IdP | AWS SSO, Salesforce, GitHub Enterprise |
| Federation | Allowing an SP to trust identities from an external IdP | AWS trusting Okta for console login |
Security Assertion Markup Language (SAML) 2.0 is an XML-based open standard for exchanging authentication data between an IdP and an SP.
Typical SP-initiated flow:
The XML assertion is signed using the IdP's private key; the SP verifies using the IdP's public key certificate registered at setup. An attacker who intercepts a SAML assertion cannot replay it beyond the assertion's expiry (typically 5 minutes).
Key security control: Always verify the IdP certificate is up-to-date and rotate it before expiry. A SAML federation with an expired certificate silently breaks authentication.
OIDC is an identity layer built on top of OAuth 2.0, using JSON Web Tokens (JWTs) instead of XML. It is lighter than SAML and has become the standard for API-to-API authentication and modern web application SSO.
| Component | SAML 2.0 | OIDC |
|---|---|---|
| Token format | XML Assertion | JWT (JSON Web Token) |
| Primary use | Enterprise SSO (web browser) | API auth, mobile, SPA, OIDC SSO |
| Discovery | Manual metadata file exchange | Well-Known URL (/.well-known/openid-configuration) |
| Signing | XML Digital Signature (RSA/SHA-256) | RS256 / ES256 JWT signature |
OIDC in cloud context: GitHub Actions uses OIDC to authenticate to AWS. When a CI/CD pipeline runs, GitHub generates an OIDC token that AWS STS validates. AWS grants a temporary IAM role to the pipeline — no long-lived access keys stored in GitHub Secrets.
OAuth 2.0 is an authorisation framework, not an authentication protocol. It allows an application to obtain delegated access to a resource on behalf of a user (access tokens) or on behalf of itself (client credentials).
Common grant types:
| Grant Type | Use Case | Security Note |
|---|---|---|
| Authorization Code + PKCE | Web/mobile apps, user-facing | Most secure; PKCE prevents code interception |
| Client Credentials | Machine-to-machine (no user) | Rotate client secrets; use short expiry |
| Implicit (deprecated) | Old SPAs | Do not use; vulnerable to token leakage |
| Device Code | IoT, CLI tools | Limited time window; displayed code is the second factor |
MFA is the single highest-impact security control in cloud environments. AWS's own threat intelligence team has stated that enabling MFA would have prevented more than 99% of the account compromises they responded to.
| MFA Method | Phishing Resistant? | Recommended For |
|---|---|---|
| TOTP (Authenticator App) | No — real-time phishing possible | Standard user accounts |
| SMS OTP | No — SS7 attack, SIM swap possible | Avoid for privileged accounts |
| FIDO2/WebAuthn (Hardware Key) | Yes | Privileged users, administrators, root account |
| Push Notification | No — push fatigue attacks | Disable for privileged users |
For the AWS root account: use a hardware FIDO2 key (YubiKey). Store it physically in a secure location. The root account should log in fewer than five times per year.
AWS IAM Identity Center is the recommended way to provide human users access to multiple AWS accounts and applications:
This approach eliminates per-account IAM users, centralises audit in the IdP, and ensures that when an employee leaves and their Okta account is deprovisioned, they lose access to all AWS accounts automatically.
