What Is Authentication vs Authorization?
MediumHotMajor: software engineeringokta, google
Concept
Authentication and Authorization are two distinct but complementary concepts in software security.
They determine who can access a system and what actions they can perform.
- Authentication (AuthN) verifies identity — confirming who the user is.
- Authorization (AuthZ) defines permissions — determining what the user can do after authentication.
Together, they form the backbone of secure access control in applications, APIs, and systems.
1. Authentication — Verifying Identity
Definition:
Authentication is the process of verifying that a user or system is who they claim to be.
It typically involves credentials like passwords, biometrics, or tokens.
Common Methods:
- Password-based: Username/password combinations.
- Token-based: JWT, OAuth 2.0 access tokens.
- Multi-Factor Authentication (MFA): Combines two or more methods (e.g., password + OTP).
- Biometric: Fingerprint, face recognition.
- SSO (Single Sign-On): One login grants access across multiple systems.
Example (safe for MDX):
User: alice@example.com
Password: ********
→ Verified identity = Alice
Outcome: System confirms the identity is valid but does not yet determine what Alice can do.
2. Authorization — Controlling Access
Definition: Authorization determines the resources and actions an authenticated user is permitted to access.
Common Models:
- RBAC (Role-Based Access Control): Access determined by user roles (e.g., Admin, Editor, Viewer).
- ABAC (Attribute-Based Access Control): Based on user attributes (e.g., department, location).
- PBAC (Policy-Based Access Control): Uses policies to define access rules (e.g., XACML).
Example (safe for MDX):
Alice → Authenticated as "user"
System checks role: "admin" required
→ Access Denied (Authorization failed)
Outcome: Even though Alice is authenticated, she’s not authorized for admin-level actions.
3. Comparison Table
| Aspect | Authentication | Authorization |
|---|---|---|
| Definition | Verifies user identity | Grants or restricts permissions |
| Order | Always first | Always follows authentication |
| Primary Question | “Who are you?” | “What are you allowed to do?” |
| Data Source | Credentials (username, password, token) | Role/permission database or policy |
| Outcome | Confirms identity | Grants or denies resource access |
| Example | Logging into Google account | Accessing Google Drive admin console |
| Standards | OAuth 2.0, OpenID Connect, SAML (for AuthN) | RBAC, ABAC, ACLs (for AuthZ) |
4. Example Flow: Login to a Web App
Scenario:
- Authentication:
The user logs in using credentials (
email+password). The system verifies the identity via an authentication server (e.g., Okta, Auth0, or Firebase Auth). - Authorization: Once authenticated, the system checks if the user’s role or token grants access to requested resources (e.g., admin dashboard).
Flow Diagram (safe for MDX):
[Login Form] → [Auth Server verifies identity] → [JWT issued]
↓
[App checks roles/permissions] → [Access Granted or Denied]
5. Real-World Implementations
| Example | Authentication | Authorization |
|---|---|---|
| Google Workspace | Logging in with Gmail credentials | Accessing Drive folders based on sharing permissions |
| AWS Console | IAM user login via password/MFA | IAM policy grants access to S3 or EC2 |
| GitHub | OAuth via GitHub account | Repo access limited to collaborators or teams |
| Bank App | Biometric login or PIN | Transaction limits based on user role or account type |
6. Common Standards and Protocols
| Category | Standard | Description |
|---|---|---|
| Authentication | OAuth 2.0 | Delegated access via tokens. |
| OpenID Connect (OIDC) | Identity layer on top of OAuth for user login. | |
| SAML 2.0 | XML-based authentication standard for enterprise SSO. | |
| Authorization | RBAC/ABAC | Role- or attribute-based permissions. |
| OAuth Scopes | Define permission levels for tokens. | |
| JWT Claims | Embed authorization data within tokens. |
Example (safe for MDX):
Access Token Scopes:
read:profile
write:email
→ Authorization rules based on token scope
7. Security Best Practices
- Separate AuthN and AuthZ logic: Use dedicated services (e.g., Okta, Auth0).
- Use HTTPS: Prevent credential interception.
- Implement MFA: Protect against stolen credentials.
- Use short-lived tokens: Reduce risk if compromised.
- Log access and authorization decisions: Detect anomalies.
- Principle of Least Privilege (PoLP): Grant only necessary permissions.
8. Common Pitfalls
| Issue | Description |
|---|---|
| Confusing AuthN and AuthZ | Developers often use terms interchangeably, leading to design flaws. |
| Over-permissive roles | Assigning users broad roles (e.g., “Admin”) instead of granular access. |
| Token misuse | Not validating token scopes or expiration. |
| Static access lists | Hardcoded permissions that hinder flexibility and security. |
9. Analogy for Understanding
| Concept | Analogy |
|---|---|
| Authentication | Showing your ID to a security guard — confirms who you are. |
| Authorization | The guard checking if your ID allows entry into a specific room. |
Interview Tip
- Define both terms clearly and emphasize order (AuthN before AuthZ).
- Mention real-world protocols (OAuth 2.0, OpenID Connect).
- Give a practical example (e.g., AWS IAM or web app with roles).
- Stress principle of least privilege and token-based authorization in modern systems.
Summary Insight
Authentication verifies identity — “Who are you?” > Authorization enforces permissions — “What can you do?” Together, they form the foundation of secure and accountable access control.