What Is Cloud IAM → Authentication vs Authorization → IAM Roles vs Policies
TL;DR
- Authentication asks are you who you claim to be? Authorization asks are you allowed to do this? — two separate gates, two separate failure modes
- AWS
AccessDeniedis an authorization failure — the identity authenticated fine; fix the policy, not the credentials - Prefer short-lived credentials (STS temporary tokens, Managed Identities) over long-lived access keys — the difference is the blast radius window
- MFA strengthens authentication; it does nothing for authorization — a hijacked session with broad permissions is just as dangerous with or without MFA on the original login
HTTP 401= authentication failure;HTTP 403= authorization failure — the code tells you which gate to debug- Both layers must enforce least privilege independently — application-layer authorization is not a substitute for tight cloud IAM
The Big Picture
Every API call in the cloud passes through two gates before it executes. Most engineers know the first one. The second is where most security failures live.
THE TWO GATES — every cloud API call passes through both, in order
┌──────────────────────────────────────────────────────────────────┐
│ GATE 1 — AUTHENTICATION │
│ "Are you who you claim to be?" │
│ │
│ IAM user → Access Key + Secret (long-lived, rotatable) │
│ IAM role → Temporary STS token (expires automatically) │
│ Human → Password + MFA via console or IdP │
│ Service → Instance profile / Managed Identity / OIDC │
│ │
│ Passes → move to Gate 2 │
│ Fails → stopped here, HTTP 401 │
└──────────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────┐
│ GATE 2 — AUTHORIZATION │
│ "Are you allowed to do what you're trying to do?" │
│ │
│ Evaluated against: identity-based policies · SCPs │
│ resource-based policies · conditions │
│ permissions boundaries · session policies │
│ │
│ Default answer: DENY (explicit Allow required every time) │
│ │
│ Passes → request executes │
│ Fails → AccessDenied / HTTP 403 │
└──────────────────────────────────────────────────────────────────┘
MFA hardens Gate 1. It has zero effect on Gate 2.
A hijacked session with a valid token clears Gate 1 automatically.
Gate 2 is your last line of defense — and the one that's most often misconfigured.
Introduction
The authentication vs authorization distinction is the most commonly confused boundary in cloud security — and the source of most misdirected debugging when an AWS AccessDenied error appears. These are two separate gates, two separate failure modes, and two entirely different fixes.
Early in my career I wrote an API endpoint I was proud of. Token validation. Rejection of unauthenticated requests. I called it “secured” in the code review.
A senior engineer asked one question: “What happens if I take a valid token from a regular user and call your /admin/delete-user endpoint?”
I ran the test. It worked. Any employee — with a perfectly valid, properly issued token — could delete any user account in the system.
The authentication was correct. The authorization didn’t exist.
That gap between proving who you are and proving you’re allowed to do this is where a surprising number of security incidents live. Not just in application code. In cloud IAM too. I’ve reviewed AWS environments where MFA was enforced on every human account, access keys were rotated quarterly, and yet a Lambda function had s3:* on * because whoever wrote the deployment script reached for AmazonS3FullAccess and moved on.
Gate 1 was solid. Gate 2 was wide open.
This episode draws the boundary cleanly — what each gate is, how each cloud implements it, and the specific failure modes that happen when the two get conflated.
How Authentication Works in Cloud IAM
Authentication answers: are you who you claim to be?
The three factor types
Authentication has not fundamentally changed in decades. What has changed is how cloud platforms implement it.
| Factor | Type | Cloud Examples |
|---|---|---|
| Something you know | Knowledge | Password, access key secret, PIN |
| Something you have | Possession | TOTP app, FIDO2 hardware key, smart card |
| Something you are | Inherence | Biometrics — less common in cloud contexts |
MFA requires two distinct factors. A password plus a username is not MFA — both are knowledge factors. A password plus a TOTP code is MFA. Worth stating clearly because I’ve seen internal documentation describe “username and password” as two-factor authentication.
SMS codes count as MFA, but they’re the weakest form. SIM-swapping attacks — convincing a carrier to port your number — have been used to defeat SMS MFA on high-value accounts. If TOTP or FIDO2 hardware keys are available, use them.
How AWS authenticates
AWS has two fundamentally different identity classes:
Human identities authenticate via console (password + optional MFA) or CLI/API (Access Key ID + Secret Access Key). The access key is a long-lived credential with no default expiry. Every .env file with an access key, every git commit that included one, every CI/CD log that printed one — that credential is live until someone explicitly rotates or deletes it.
Machine identities — EC2, Lambda, ECS tasks — authenticate via temporary credentials issued by STS:
# Assume a role — get temporary credentials that expire
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/DevRole \
--role-session-name alice-session \
--duration-seconds 3600
# Returns: AccessKeyId + SecretAccessKey + SessionToken
# All three expire together. Nothing to rotate.
# From inside an EC2 instance — credentials arrive automatically via IMDS
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/MyAppRole
# Returns: AccessKeyId, SecretAccessKey, Token, Expiration
# AWS refreshes these before expiry. The application never sees a rotation event.
The IMDS model is the right one. The application never manages a credential — it appears, it’s used, it expires. If it leaks, it’s usable for hours at most, not years.
How GCP authenticates
GCP cleanly separates human and machine authentication.
Humans authenticate via Google Account or Workspace (OAuth2). The gcloud CLI handles the flow:
gcloud auth login # browser-based OAuth2 for humans
gcloud auth application-default login # sets up Application Default Credentials for local dev
Machine identities use service accounts, ideally attached to the resource rather than using downloaded key files. Key files are GCP’s equivalent of long-lived AWS access keys — same problems, same risks.
# From inside a GCE VM — ADC uses the attached service account, no key file needed
gcloud auth print-access-token
# Use it: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" ...
How Azure authenticates
Azure’s identity plane is Entra ID (formerly Azure Active Directory). Humans authenticate via Entra ID using OAuth2/OIDC. Machine identities use Managed Identities — Azure handles the entire credential lifecycle, nothing to configure or rotate.
az login # browser-based OAuth2
az login --service-principal \ # service principal for automation
-u APP_ID -p CERT_OR_SECRET \
--tenant TENANT_ID
# From inside an Azure VM — get a token via IMDS, no credentials needed
curl 'http://169.254.169.254/metadata/identity/oauth2/token\
?api-version=2018-02-01&resource=https://management.azure.com/' \
-H 'Metadata: true'
The credential failure modes that repeat everywhere
Across all three clouds, the same patterns appear in every audit:
Leaked credentials — access keys in git commits, .env files, Docker image layers, CI/CD logs. GitHub’s secret scanning finds thousands of these monthly on public repos alone.
Long-lived credentials — an access key from 2019 is still valid in 2026 unless someone explicitly rotated it. I’ve audited accounts where 30% of access keys had never been rotated, some five years old.
Shared credentials — one key used by three services. When you revoke it, three things break. When it leaks, you can’t tell which service was the source.
Credential sprawl — service account keys downloaded for “one quick test” and never deleted. I once found seventeen key files for a single GCP service account, created by different engineers over two years. None rotated. Five belonged to accounts that no longer existed.
The direction of travel in all three clouds is credential-less: workload identity federation, managed identities, instance profiles. We’ll cover this specifically in OIDC Workload Identity: Eliminate Cloud Access Keys Entirely.
How Authorization Evaluates Every API Call
Authorization happens after authentication. The system knows who you are — now it decides what you can do. This decision is enforced through IAM roles vs policies — the building blocks that express what each identity is allowed to do on which resources.
What the evaluation looks like
Every API call triggers an authorization check. You don’t notice when it succeeds. You notice when it fails:
REQUEST:
Action: s3:DeleteObject
Resource: arn:aws:s3:::prod-backups/2024-01-15.tar.gz
Principal: arn:aws:iam::123456789012:role/DevEngineerRole
Context: { source_ip: "10.0.1.5", mfa: false, time: "14:32 UTC" }
EVALUATION:
1. Explicit Deny anywhere? → none found
2. Explicit Allow in any policy? → not granted
3. Default → DENY
RESULT: AccessDenied
The engineer authenticated successfully. Valid credentials, valid session. But DevEngineerRole has no policy granting s3:DeleteObject on that bucket. Gate 1 passed. Gate 2 denied. They are evaluated independently.
Policy evaluation chains by cloud
AWS — evaluated in layers, explicit Deny wins at any layer:
1. Explicit Deny in any SCP? → DENY (cannot be overridden anywhere)
2. No SCP Allow? → DENY
3. Explicit Deny in identity or resource policy? → DENY
4. Resource-based policy Allow? → can ALLOW (same account)
5. Permissions boundary — no Allow? → DENY
6. Session policy — no Allow? → DENY
7. Identity-based policy Allow? → ALLOW
Default (nothing granted): → DENY
The default is always Deny. Every successful authorization is an explicit "Effect": "Allow" somewhere in the chain. This is the opposite of traditional Unix — in the cloud, if you didn’t explicitly grant it, it doesn’t exist.
GCP — additive, permissions accumulate up the hierarchy:
Permission granted if ANY binding grants it at:
resource level → project level → folder level → organization level
IAM Deny Policies can override all grants (newer feature).
No binding at any level? → Denied.
Azure RBAC:
1. Explicit Deny Assignment? → DENY (even Owner can't override)
2. Role Assignment with Allow? → ALLOW
Default: → DENY
Why Confusing Authentication and Authorization Breaks Security
The token-as-authorization antipattern
An application checks for a valid JWT and if found, proceeds. The JWT proves the user authenticated with the IdP. It says nothing about what they’re allowed to do.
# This is authentication only — anyone with a valid token gets through
@app.route("/admin/delete-user", methods=["POST"])
def delete_user():
token = request.headers.get("Authorization")
if verify_token(token): # asks: is this token real and unexpired?
delete_user_from_db(...) # executes for any valid token holder
return "OK"
return "Unauthorized", 401
# This separates the two correctly
@app.route("/admin/delete-user", methods=["POST"])
def delete_user():
token = request.headers.get("Authorization")
principal = verify_token(token) # Gate 1: authentication
if not has_permission(principal, "users:delete"): # Gate 2: authorization
return "Forbidden", 403
delete_user_from_db(...)
return "OK"
The short-expiry principle
| Credential type | Provider | Typical lifetime | Risk |
|---|---|---|---|
| Access Key + Secret | AWS | Permanent (until deleted) | Years of exposure if leaked |
| STS Temporary Token | AWS | 15 min – 12 hours | Hours at most |
| OAuth2 Access Token | GCP / Azure | ~1 hour | Short window |
| IMDS Token (VM) | All three | Minutes | Auto-refreshed by platform |
A credential that expires in an hour has a one-hour exposure window if stolen. A credential that never expires has an unlimited window. This is the operational argument for managed identities and instance profiles, beyond just convenience.
# AWS — configure max session duration at role level
aws iam update-role \
--role-name MyRole \
--max-session-duration 3600 # 1 hour max
# GCP — access tokens expire in ~1 hour automatically
gcloud auth print-access-token
# Refresh: gcloud auth application-default print-access-token
# Azure — token lifetime configurable in Entra ID token policies
az account get-access-token --resource https://management.azure.com/
⚠ Production Gotchas
╔══════════════════════════════════════════════════════════════════════╗
║ ⚠ GOTCHA 1 — "We have MFA, so permissions can be broad" ║
║ ║
║ MFA protects Gate 1 only. If a session is hijacked after login ║
║ (via malware, SSRF, or a stolen session cookie), the attacker has ║
║ a valid, MFA-authenticated token. Gate 1 is already cleared. ║
║ Broad permissions in Gate 2 are the full attack surface. ║
║ ║
║ Fix: treat Gate 2 (IAM policy) as your primary blast-radius ║
║ control. MFA buys time. Least privilege limits damage. ║
╚══════════════════════════════════════════════════════════════════════╝
╔══════════════════════════════════════════════════════════════════════╗
║ ⚠ GOTCHA 2 — Debugging AccessDenied by rotating credentials ║
║ ║
║ AWS AccessDenied is an authorization failure. The identity ║
║ authenticated successfully — there's no Allow in the policy. ║
║ Rotating the access key does nothing. ║
║ ║
║ Fix: check the policy chain. Use simulate-principal-policy to ║
║ confirm where the Allow is missing before touching credentials. ║
╚══════════════════════════════════════════════════════════════════════╝
╔══════════════════════════════════════════════════════════════════════╗
║ ⚠ GOTCHA 3 — Application-layer authZ with broad cloud IAM ║
║ ║
║ "The app controls access" is not a substitute for scoped cloud ║
║ IAM. An SSRF vulnerability, exposed debug endpoint, or ║
║ compromised dependency bypasses the application layer entirely. ║
║ The cloud identity's permissions become the attacker's surface. ║
║ ║
║ Fix: both layers enforce least privilege independently. ║
╚══════════════════════════════════════════════════════════════════════╝
Authentication vs Authorization Audit Checklist
Split your IAM review along the authN/authZ boundary — they’re different problems with different fixes.
Authentication — Gate 1:
– Are there long-lived access keys that could be replaced with STS/Managed Identity?
– Is MFA enforced for all human identities with console or API access?
– Are service account key files present where workload identity is available?
– Are credentials stored in a secrets manager — not in code, .env files, or repos?
– When did each long-lived credential last rotate?
Authorization — Gate 2:
– Does every policy follow least privilege — only the permissions the workload actually uses?
– Are there wildcards (s3:*, "Resource": "*") that could be narrowed?
– Are write, delete, and IAM-modification actions scoped to specific resources?
– Are SCPs or permissions boundaries capping maximum permissions at org or account level?
– When were each role’s permissions last reviewed against actual usage (Access Analyzer)?
Quick Reference
┌────────────────────────────┬──────────────────────────────────────────────────┐
│ Term │ What it means │
├────────────────────────────┼──────────────────────────────────────────────────┤
│ Authentication (AuthN) │ Verifying identity — are you who you claim? │
│ Authorization (AuthZ) │ Verifying permission — are you allowed to act? │
│ MFA │ Two distinct factors; strengthens Gate 1 only │
│ STS (AWS) │ Security Token Service — issues temp credentials │
│ Access Key │ Long-lived AWS credential; avoid for services │
│ Instance profile (AWS) │ Container attaching a role to EC2 │
│ Managed Identity (Azure) │ Credential-less identity for Azure services │
│ Service Account (GCP) │ Machine identity; prefer attached over key file │
│ HTTP 401 │ Authentication failure — prove who you are │
│ HTTP 403 / AccessDenied │ Authorization failure — fix the policy │
└────────────────────────────┴──────────────────────────────────────────────────┘
Commands to know:
┌──────────────────────────────────────────────────────────────────────────────┐
│ # AWS — assume a role and get temporary credentials │
│ aws sts assume-role --role-arn arn:aws:iam::ACCOUNT:role/ROLE \ │
│ --role-session-name my-session --duration-seconds 3600 │
│ │
│ # AWS — simulate a policy to debug AccessDenied before touching anything │
│ aws iam simulate-principal-policy \ │
│ --policy-source-arn arn:aws:iam::ACCOUNT:role/MyRole \ │
│ --action-names s3:GetObject \ │
│ --resource-arns arn:aws:s3:::my-bucket/* │
│ │
│ # AWS — check what credentials your session is using │
│ aws sts get-caller-identity │
│ │
│ # GCP — print the current access token (expires in ~1 hour) │
│ gcloud auth print-access-token │
│ │
│ # GCP — show which account ADC is using │
│ gcloud auth application-default print-access-token │
│ │
│ # Azure — get current token for ARM │
│ az account get-access-token --resource https://management.azure.com/ │
│ │
│ # Azure — check who you're logged in as │
│ az account show │
└──────────────────────────────────────────────────────────────────────────────┘
Framework Alignment
| Framework | Reference | What It Covers Here |
|---|---|---|
| CISSP | Domain 5 — Identity and Access Management | AuthN and AuthZ are the two core mechanisms; this episode defines the boundary |
| CISSP | Domain 1 — Security & Risk Management | Conflating the two creates systematic, measurable risk with different attack surfaces |
| ISO 27001:2022 | 5.17 Authentication information | Managing credentials and authentication mechanisms across the identity lifecycle |
| ISO 27001:2022 | 8.5 Secure authentication | Technical controls — MFA, session management, credential policies |
| ISO 27001:2022 | 5.15 Access control | Policy requirements that depend on cleanly separating identity from permission |
| SOC 2 | CC6.1 | Logical access controls — this episode defines the two-gate model CC6.1 is built on |
| SOC 2 | CC6.7 | Access restrictions enforced at the authorization layer, not just authentication |
Key Takeaways
- Authentication proves identity; authorization proves permission — two gates, two separate failure modes, two separate fixes
- AWS
AccessDeniedis a Gate 2 failure — the credential is valid, the policy is missing; fix the policy - Short-lived credentials (STS, Managed Identities, instance profiles) reduce the blast radius of a credential compromise from years to hours
- MFA hardens Gate 1 — it has no effect on what an authenticated identity can do
- HTTP 401 = Gate 1 failed; HTTP 403 = Gate 2 failed — the status code tells you where to look
- Application-layer authorization and cloud IAM authorization are independent — both must enforce least privilege
What’s Next
You now know what the two gates are and where failures in each originate. IAM Roles vs Policies: How Cloud Authorization Actually Works goes into the mechanics of Gate 2 — the permissions, policies, and roles that implement authorization in practice, and the structural patterns that keep them from turning into an unmanageable sprawl.
Next: IAM Roles vs Policies: How Cloud Authorization Actually Works
Get the IAM roles vs policies breakdown in your inbox when it publishes → linuxcent.com/subscribe