Authentication and authorization are the two fundamental access control mechanisms in every secure system, and confusing them — or misconfiguring either — is one of the most common causes of data breaches. Authentication answers “who are you?” Authorization answers “what are you allowed to do?” Both are required, in that order, and a failure in either creates exploitable vulnerabilities regardless of how well the other is implemented.
How Authentication Works: Verifying Identity
Authentication is the process of verifying that a principal (user, service, or device) is who it claims to be. The NIST SP 800-63B Digital Identity Guidelines define three authentication factors: something you know (password, PIN), something you have (hardware token, TOTP app, smart card), and something you are (biometric). Modern authentication protocols implement these factors across several standards:
- Password-based authentication: passwords remain the most common factor, but must be stored as salted hashes (bcrypt, Argon2, scrypt) — never in plaintext or reversible encryption. OWASP’s Authentication Cheat Sheet sets the current minimum bar for implementation.
- Time-based One-Time Passwords (TOTP): defined in RFC 6238, generate a new 6-digit code every 30 seconds from a shared secret — used by Google Authenticator, Authy, and similar apps.
- Hardware security keys (FIDO2/WebAuthn): the most phishing-resistant authentication factor, standardized by the FIDO Alliance. The authenticator performs a cryptographic challenge-response that is bound to the specific origin, so cloned phishing sites cannot harvest credentials.
- Certificate-based authentication: used in enterprise and machine-to-machine contexts (mTLS), where both parties present X.509 certificates. Common in zero-trust architectures.
Multi-factor authentication (MFA) requires at least two different factor types. SMS-based OTP technically qualifies but is considered weak due to SIM-swapping attacks — NIST 800-63B no longer recommends it as a sole second factor.
How Authorization Works: Controlling Access After Login
Authorization determines what an authenticated principal can do. The most widely deployed authorization model in enterprise systems is Role-Based Access Control (RBAC), where permissions are assigned to roles and users are assigned to roles. A database administrator role grants full schema access; a reporting role grants read-only access to specific tables. NIST formalized RBAC in NIST SP 800-162.
More granular environments use Attribute-Based Access Control (ABAC), where authorization decisions are made by evaluating policies against attributes of the user, the resource, and the environment (time of day, IP range, device posture). ABAC enables policies like “allow finance staff to access payroll data only from corporate-managed devices during business hours.”
The foundational security principle for authorization is least privilege: every principal receives the minimum access required for its function. Excessive permissions accumulate over time through role inheritance and ad-hoc grants — a pattern called “privilege creep” that is regularly exploited in lateral movement attacks after initial compromise.
Critical Differences and Common Misconfigurations
Authentication and authorization are sequential and non-interchangeable. A system that authenticates correctly but has broken authorization logic suffers from Broken Access Control — the #1 vulnerability category in the OWASP Top 10 (2021). Common failure patterns include:
- Forced browsing: authenticated user increments an ID in a URL and accesses another user’s data because the server never checks ownership.
- Missing function-level access control: an admin endpoint is only hidden from the UI, not protected server-side — any authenticated user can call it directly.
- JWT privilege escalation: applications that accept unsigned or algorithm-none JWTs allow attackers to forge tokens claiming elevated roles.
- IDOR (Insecure Direct Object Reference): resources are accessed by predictable identifiers with no server-side ownership verification.
OAuth 2.0 and OpenID Connect: Authentication and Authorization in Modern APIs
Web applications and APIs typically implement authentication and authorization through OAuth 2.0 (RFC 6749) and OpenID Connect (OIDC). OAuth 2.0 is an authorization framework that allows a user to grant a third-party application limited access to their account without sharing credentials. OpenID Connect adds an identity layer on top of OAuth 2.0, enabling authentication via ID tokens (JWTs signed by the identity provider). The combination is the basis for “Sign in with Google/Apple/Microsoft” flows and enterprise SSO systems.
Access tokens (short-lived, 15 minutes to 1 hour) authorize specific API scopes. Refresh tokens (long-lived) allow obtaining new access tokens without re-authentication. Both must be stored securely — never in localStorage where XSS can extract them; use httpOnly cookies or secure storage APIs.
Implementing Secure Authentication and Authorization
For teams building or auditing systems, the practical baseline is:
- Enforce MFA for all accounts with privileged access — use hardware keys or TOTP, not SMS.
- Store passwords with Argon2id (preferred) or bcrypt with work factor ≥12.
- Implement server-side authorization checks on every request, not just in the UI layer.
- Apply least privilege: audit and revoke permissions quarterly; avoid wildcard grants.
- Log all authorization failures — repeated denied access to resources outside a user’s scope is an indicator of active probing or post-compromise lateral movement.
- For APIs: validate and verify JWTs server-side including algorithm, issuer, audience, and expiry claims.
