Every access decision in every system you will ever audit comes down to two questions: Who are you? and What are you allowed to do?
The first question is authentication. The second is authorization. They sound similar, they are often confused, and they are evaluated separately in every compliance framework you will encounter. Getting this distinction wrong — or letting your organization conflate the two — leads to audit findings, architectural mistakes, and security gaps that are surprisingly hard to fix after the fact.
This lesson breaks down the difference, introduces the principal/resource model that underlies all IAM systems, and explains why auditors care about the distinction as much as they do.
Dev asking for admin access 'just for five minutes'
Authentication: Proving who you are
Authentication is the process of verifying identity. When you type your password into Okta, you are authenticating. When you scan your fingerprint on your laptop, you are authenticating. When a service account presents a signed JWT to an API, it is authenticating.
The system does not yet care what you want to do. It only cares whether you are who you claim to be. Authentication answers a single question: is this identity legitimate?
Authentication mechanisms fall into three categories, and you will see these referenced in every identity standard:
- Something you know — passwords, PINs, security questions. The weakest category when used alone, because knowledge can be shared, phished, or guessed.
- Something you have — a hardware security key, a phone receiving a push notification, a smart card. Stronger because possession is harder to replicate remotely.
- Something you are — biometrics. Fingerprint, face scan, iris scan. The hardest to forge, but also the hardest to revoke if compromised (you cannot rotate your fingerprint).
Multi-factor authentication (MFA) combines two or more of these categories. When Okta asks for your password and then sends a push notification to your phone, that is two-factor authentication: something you know plus something you have.
Real-world authentication examples
- A developer logs into the AWS console with a username, password, and a TOTP code from an authenticator app. That is authentication — three credentials proving identity.
- A CI/CD pipeline presents an OIDC token to AWS STS to assume a role. That is authentication — the token proves the pipeline's identity.
- An employee badges into a data center with a proximity card and a PIN. That is authentication — something you have plus something you know.
In all three cases, the system has not yet decided whether the principal is allowed to do anything. It has only confirmed that the principal is real.
Authorization: Deciding what you can do
Authorization is the process of determining what an authenticated identity is permitted to access. After the system knows who you are, it evaluates what you are allowed to do.
When you log into AWS and try to launch an EC2 instance, the IAM policy engine checks whether your user or role has the ec2:RunInstances permission. That check is authorization. When a developer tries to merge a pull request and GitHub checks whether they have write access to the repository, that is authorization. When a conditional access policy in Entra ID blocks a user from accessing email because they are on an unmanaged device, that is authorization.
Authorization depends on authentication — you cannot decide what someone is allowed to do until you know who they are — but it is a fundamentally different operation. Authentication validates identity. Authorization enforces policy.
Real-world authorization examples
- An IAM role in AWS has a policy allowing
s3:GetObjecton a specific bucket but nots3:PutObject. That policy is an authorization control — it defines what the role can do after authentication succeeds. - A service account in GCP is granted the
roles/bigquery.dataViewerrole. That role binding is authorization. - An SCP (Service Control Policy) in AWS Organizations prevents any principal in a member account from disabling CloudTrail. That SCP is an authorization control — it restricts what authenticated principals can do regardless of their individual permissions.
The principal/resource model
All IAM systems, regardless of vendor, operate on the same fundamental model: a principal requests access to a resource, and the system evaluates that request through authentication and authorization checks.
Principals are entities that can request access. They include:
- Users — human identities. An employee with an Okta account, an AWS IAM user, an Entra ID account.
- Service accounts — machine identities. A Kubernetes service account, a GCP service account, an AWS IAM role assumed by an application.
- Roles — collections of permissions that principals can assume. An AWS IAM role, an Azure RBAC role, a GCP predefined role.
- Groups — collections of principals that share permissions. An Okta group, an AWS IAM group, an Entra ID security group.
Resources are things that principals want to access. They include:
- Files and objects (S3 buckets, GCS objects, Azure Blob Storage)
- APIs and services (REST endpoints, Lambda functions, Cloud Run services)
- Databases (RDS instances, Cloud SQL, Cosmos DB)
- Infrastructure (EC2 instances, GKE clusters, Azure VMs)
- Applications (SaaS tools, internal dashboards, admin consoles)
The flow is always the same:
┌─────────────┐ Request ┌──────────────────┐
│ Principal │────────────────►│ Authentication │
│ (user, │ │ "Who are you?" │
│ service │ │ │
│ account, │ │ Verify: │
│ role) │ │ - Credentials │
│ │ │ - MFA │
└─────────────┘ │ - Token validity │
└────────┬───────────┘
│
Identity verified?
No ──► 401 Unauthorized
│
Yes
│
▼
┌──────────────────┐
│ Authorization │
│ "What can you │
│ do?" │
│ │
│ Evaluate: │
│ - IAM policies │
│ - Role bindings │
│ - Resource policies│
│ - SCPs / boundaries│
└────────┬───────────┘
│
Permission granted?
No ──► 403 Forbidden
│
Yes
│
▼
┌──────────────────┐
│ Resource │
│ (file, API, │
│ database, │
│ service) │
└──────────────────┘Every access decision follows this path: principal requests access, authentication verifies identity, authorization checks permissions, resource is accessed or denied
Notice the HTTP status codes in the diagram. A 401 Unauthorized means authentication failed — the system does not know who you are. A 403 Forbidden means authorization failed — the system knows who you are but you do not have permission. This distinction shows up in logs, in incident investigations, and in audit evidence.
Edge cases that matter
Not every access mechanism fits neatly into one bucket. Understanding the edge cases is what separates a GRC engineer who can write accurate control narratives from one who glosses over the details.
API keys: Authentication without identity
An API key proves that the request comes from an authorized source, but it does not identify a specific user. If three developers share an API key, the system knows the key is valid (authentication) but cannot attribute the request to a specific person. This is why API keys are considered a weak authentication mechanism for audit purposes — they provide no user-level attribution.
For auditors, this matters. If a SOC 2 control requires individual accountability for access (CC6.1), API keys shared across a team fail to meet that requirement. The key authenticates the request, but without user identity, you cannot demonstrate individual access control.
Service accounts: Machine identity
Service accounts are non-human principals that represent applications or services. A Kubernetes pod running with a service account, or a GCP service account attached to a Cloud Function, authenticates as a machine identity rather than a human one.
The compliance obligation is the same as for human identities: service accounts must follow least privilege, must have their access reviewed, and must have their credentials rotated. In practice, service accounts are more likely to be overprivileged than human accounts because they are set up once during initial deployment and rarely reviewed afterward.
Federated identity: Outsourcing authentication
When your company uses Okta to SSO into AWS, Okta handles authentication (verifying the user's password and MFA) and AWS handles authorization (evaluating IAM policies). Authentication is federated to the identity provider. Authorization stays with the resource provider.
This split is critical for GRC. When an auditor asks about authentication controls, you point to Okta — MFA enforcement, password policy, session timeouts. When they ask about authorization controls, you point to AWS — IAM policies, role boundaries, SCPs. One control domain, two different systems, two different evidence packages.
Quick check
A developer authenticates via Okta SSO into the AWS console, then tries to create a new IAM user but receives an 'Access Denied' error. Which phase failed?
Conditional access: When authentication and authorization blur
Microsoft's Conditional Access policies in Entra ID sit at the intersection. A policy that requires MFA for all users accessing Exchange Online is primarily an authentication control — it strengthens identity verification. A policy that blocks access from unmanaged devices is primarily an authorization control — it restricts access based on device posture, not identity.
Some Conditional Access policies enforce both simultaneously: require MFA (authentication) AND require a managed device (authorization) before granting access to sensitive applications. This is why auditors sometimes classify Conditional Access as "Both."
Quick check
A company uses a shared API key embedded in a backend service to access a third-party vendor's API. An auditor asks whether this satisfies the requirement for individual accountability under SOC 2 CC6.1. What is the correct assessment?
GRC Engineer's lens
Why does this distinction matter for your audit work? Because auditors evaluate authentication controls and authorization controls separately. In SOC 2, authentication maps primarily to CC6.1 (logical access security) — how you verify that users are who they claim to be. Authorization maps primarily to CC6.3 (role-based access and least privilege) — how you ensure users can only access what they need. If you conflate the two in your control narratives, the auditor will flag it. If you implement strong authentication but weak authorization (or vice versa), you will have findings in one area despite passing the other. Treating them as separate control domains is not pedantic — it is how the audit works.
The distinction in practice
Here is why this matters beyond passing an audit. Consider a real scenario:
A company implements Okta with MFA for all employees. Strong authentication. Then they grant every employee the AWS AdministratorAccess managed policy because "it's easier than figuring out what permissions each team needs." They have excellent authentication and catastrophic authorization.
An auditor reviewing CC6.1 would find the authentication controls satisfactory — Okta, MFA enforced, password policies configured. But reviewing CC6.3 would produce a critical finding: no role-based access control, no least privilege, every user has unrestricted administrative access.
The reverse also happens. A company builds a meticulous RBAC model in AWS with carefully scoped IAM policies, permission boundaries, and SCPs. But they allow IAM users with static access keys and no MFA. Excellent authorization, weak authentication. An attacker who compromises a leaked access key inherits whatever permissions the key holder had.
Both controls must be strong for the system to be secure. Both controls must be documented for the audit to pass. Both controls are your responsibility as a GRC engineer.
Quick check
Which pair correctly matches the HTTP status codes to the IAM phase that failed?
What to carry forward
Authentication and authorization are the two pillars of every IAM system. They are evaluated separately in every compliance framework. They require different controls, different evidence, and different engineering work. Every lesson in this module builds on this distinction — from how IAM policies are evaluated, to how access reviews work, to how you write control narratives that auditors actually accept.
When you encounter an IAM configuration in the wild — an Okta policy, an AWS IAM role, a GCP service account binding — the first question to ask yourself is: is this an authentication control or an authorization control? The answer determines which audit criteria it maps to, what evidence you need to collect, and where it belongs in your control library.