Authentication vs Authorization: What’s the Difference?

Authentication vs authorization is one of the most important distinctions in security and IAM: authentication (AuthN) verifies who you are, while authorization (AuthZ) determines what you’re allowed to do. Getting both right—especially in APIs, admin panels, and multi-tenant apps—is foundational to access control.

How authentication works (AuthN)

Authentication typically has four phases:

1. Claim an identity - Example: username, email, device ID, service account name, certificate subject.
2. Present evidence (a credential) - Something you know: password, PIN - Something you have: hardware key, authenticator app, smartcard - Something you are: biometrics (usually unlocking a local key, not sent as “proof”) - Something you do: behavioral signals (risk-based / adaptive)
3. Verify the evidence - Password hash comparison, FIDO2 assertion validation, certificate chain validation, OTP verification, etc.
4. Issue a session / token - A cookie-based session, or a signed token (e.g., JWT), or a Kerberos ticket.

Once authentication completes, the system can say: “This request is from Alice (or from service X).”

How authorization works (AuthZ)

Authorization begins after identity is established, and it should be checked for every protected action, not just at login.

Common authorization flow:

1. Identify the subject - The authenticated user/service (from session or token).
2. Identify the resource and action - Resource: /api/invoices/123, S3 bucket, database row, admin panel - Action: read, write, delete, approve, export, administer
3. Evaluate policy - Role-Based Access Control (RBAC): “Users with role BillingAdmin can approve invoices.” - Attribute-Based Access Control (ABAC): “Users in department X can access documents tagged X.” - Relationship-Based Access Control (ReBAC): “You can view a file if you’re in the shared folder.”
4. Decision + enforcement - Allow, deny, or step-up (e.g., require MFA again for sensitive action). - Enforcement happens in the application, API gateway, service mesh, or a policy engine.

If authorization fails, the request is denied even if authentication succeeded.

How authentication and authorization work together in common architectures

Web apps (sessions + cookies)

• AuthN happens at login. Server issues a session cookie.
• AuthZ happens on each request by checking the session identity against permissions for the requested route/data.

APIs (tokens)

• AuthN may happen at an identity provider (IdP), issuing an access token.
• AuthZ is enforced by the API, often by validating:
• token signature and expiry (part of authN assurance / token validity)
• token claims/scopes/roles (authZ inputs)
• additional internal rules (resource ownership, tenant boundaries)

Troubleshooting: is it an AuthN problem or an AuthZ problem?

Identify whether it’s AuthN or AuthZ by HTTP status

401 Unauthorized  -> usually means "not authenticated" (missing/invalid credentials)
403 Forbidden     -> usually means "authenticated, but not authorized"

(Some frameworks misuse these, but it’s still a helpful starting signal.)

Decode a JWT to inspect authZ-related claims

# Print a JWT payload (no verification; for inspection only)
python - <<'PY'
import os, json, base64
t=os.environ.get("JWT","")
p=t.split(".")[1] + "==="
print(json.dumps(json.loads(base64.urlsafe_b64decode(p)), indent=2))
PY

Look for claims like: - sub (subject / identity) - aud (audience) - exp (expiry) - iss (issuer) - scope or scp - roles / groups - tenant/org identifiers (e.g., tid, org_id)

If the user is correct (sub matches) but the expected scope/roles are missing, you’re often dealing with an authorization configuration issue (role assignment, group sync, policy mapping).

Sample log patterns

AuthN failures:
- "invalid signature"
- "token expired"
- "unknown issuer"
- "mfa required"
- "bad credentials"

AuthZ failures:
- "access denied"
- "insufficient_scope"
- "permission denied"
- "not in allowed group"
- "policy evaluation result: deny"

Real-world examples: where you’ll encounter AuthN vs AuthZ

Security and IT teams run into authentication and authorization distinctions constantly—especially during incident response and access reviews.

1) Logging into SaaS vs accessing admin features

• Authentication: you sign in to a SaaS platform with SSO + MFA.
• Authorization: you can view dashboards but can’t manage billing or create API keys because your role is “Viewer,” not “Admin.”

Common failure mode: A user insists “I can log in, so it must be working.” But the problem is role assignment or group-to-role mapping (AuthZ).

2) VPN/Wi‑Fi vs internal resource access

• Authentication: device/user authenticates to Wi‑Fi (802.1X) or VPN.
• Authorization: network segmentation/ACLs decide which subnets and services you can reach.

If you’re hardening remote access, consider pairing strong AuthN with a reputable VPN. For example, NordVPN can be part of a remote-access stack for small teams when used with good IAM and endpoint controls: Check NordVPN pricing →.

3) Cloud consoles and IAM policies

• Authentication: you authenticate to cloud console (SSO, MFA, hardware key).
• Authorization: IAM policies decide whether you can stop instances, read secrets, or modify firewall rules.

Common failure mode: Over-permissive authorization (e.g., broad admin policies) creates blast radius even if authentication is strong.

4) APIs, microservices, and service-to-service access

• Authentication: a service proves identity using a client certificate (mTLS) or a signed token.
• Authorization: the called service checks whether that identity can call POST /refunds or read another tenant’s data.

Common failure mode: The “confused deputy” scenario—service A is authenticated, but authorization doesn’t properly constrain which resources it can access. See our explainer: what is jwt confused deputy.

5) Incident response and forensics

• If an attacker stole credentials, they can pass authentication.
• The real containment lever is often authorization:
• limiting privileges (least privilege)
• enforcing just-in-time access
• constraining lateral movement via segmentation and conditional access

Rule of thumb: Strong authentication reduces account takeover risk; strong authorization reduces damage when takeover happens.