https://drive.google.com/file/d/1TIeK1rpQMfTS7lH_6Rf-Vjq5VeziDcQB/view?usp=sharing
This document explains common authentication and authorization technologies from beginner to advanced.
Authentication answers:
Who are you?
Authorization answers:
What are you allowed to do?
Identity and access management ecosystem:
Identity & Access Management (IAM)
│
├── Authentication (Who are you?)
│ ├── Password-based (user proves identity using secret password)
│ ├── Session-based (server stores login state using session cookie)
│ ├── Token-based (stateless authentication using tokens)
│ │ ├── JWT (JSON Web Token format used to carry claims securely signed)
│ │ └── Opaque Token (random token validated by server lookup)
│ ├── API Key (static key used to identify and authenticate client apps)
│ ├── Basic Auth (username/password sent with each request in encoded form)
│ ├── Passkeys / WebAuthn (passwordless authentication using public-key cryptography)
│ └── MFA / 2FA (extra authentication layer requiring multiple factors)
│
├── Authorization (What can you do?)
│ ├── OAuth2 (delegated authorization framework that grants limited API access without sharing credentials)
│ ├── RBAC (Role-Based Access Control using roles to define permissions)
│ ├── ABAC (Attribute-Based Access Control using user/resource/context attributes)
│ └── ACL (Access Control List defining permissions per user or group per resource)
│
└── Federation / SSO (Who vouches for you?)
├── OpenID Connect (OIDC) (identity layer on top of OAuth2 used for login and identity verification)
└── SAML (XML-based enterprise federation protocol for single sign-on across organizations)
Most traditional authentication mechanism.
User provides:
Username Password
Server verifies credentials.
User | Username + Password | V Server | Verify Password Hash | Allow / Deny
Server stores user state.
Client stores only a Session ID.
Step 1:
User Login
Step 2:
Server creates session.
Session ID: ABC123XYZ
Step 3:
Server stores:
ABC123XYZ
→
{
userId: 1,
role: admin
}
Step 4:
Browser receives cookie.
Set-Cookie: session_id=ABC123XYZ
Browser
|
session_id
|
V
Server
|
Session Storage
JWT stands for:
JSON Web Token
A JWT is a signed token that carries user identity information.
Header.Payload.Signature
Example:
xxxxx.yyyyy.zzzzz
User logs in.
Server creates JWT.
{
"userId": 1,
"role": "admin"
}
Server signs token.
Client stores token.
Client sends:
Authorization: Bearer eyJhbGc...
Server verifies signature.
Client | JWT | V API Server
Simple authentication using a secret key.
Example:
X-API-Key: abc123
Client | API Key | V Server | Validate Key
HTTP authentication standard.
Credentials sent every request.
Authorization: Basic am9objpwYXNzd29yZA==
Represents:
john:password
OAuth2 is an authorization framework.
OAuth2 answers:
What resources can this application access?
OAuth2 does NOT define authentication.
User clicks:
Continue with Google
Google asks:
Allow this app to access your profile?
User approves.
Google issues:
Access Token
Application accesses Google APIs.
Usually:
User
Application requesting access.
Issues tokens.
Examples:
Protected APIs.
Used for API access.
Authorization: Bearer token
Obtains new access tokens.
OIDC is an authentication layer built on top of OAuth2.
OAuth2 answers:
What can this app access?
OIDC answers:
Who is the user?
User authenticates.
Identity Provider returns:
ID Token
Typically a JWT.
Example:
{
"sub": "123456",
"email": "john@example.com",
"name": "John"
}
SAML stands for:
Security Assertion Markup Language
Enterprise identity federation protocol.
Uses XML.
Employee
|
V
Company Identity Provider
|
V
Application
SSO is a capability, not a protocol.
Goal:
Login once. Access multiple applications.
Google Login
|
+--> Gmail
+--> Drive
+--> Docs
+--> Calendar
Adds extra authentication factors.
Instead of:
Password
Use:
Password + Additional Factor
Modern passwordless authentication.
Uses:
Public Key Private Key
cryptography.
Device creates:
Public Key Private Key
Server stores:
Public Key
Device stores:
Private Key
Server sends challenge.
Device signs challenge.
Server verifies signature.
Role-Based Access Control.
Permissions based on roles.
Example:
Admin → All Permissions Manager → Reports User → Own Data
Attribute-Based Access Control.
Permissions based on attributes.
Example:
Department = Finance AND Document Department = Finance
Result:
Allow Access
Access Control List.
Permissions attached directly to resources.
Example:
budget.xlsx John → Read Alice → Read/Write Bob → Denied
Enterprise authentication protocol.
Widely used with:
User Login
|
V
Active Directory
|
Ticket
|
V
Applications
A typical enterprise architecture:
User | V OIDC Login | OAuth2 | JWT | API Gateway | Microservices | RBAC
Where:
OIDC = Authentication OAuth2 = Authorization JWT = Token Format RBAC = Permissions MFA = Additional Security
| Technology | Category | Purpose |
|---|---|---|
| Session | Authentication | Server-side login state |
| JWT | Authentication | Token-based identity |
| API Key | Authentication | Service identification |
| Basic Auth | Authentication | Username/password transport |
| OAuth2 | Authorization | Delegated access |
| OIDC | Authentication | User identity |
| SAML | Authentication/SSO | Enterprise federation |
| MFA | Authentication | Additional verification |
| Passkeys | Authentication | Passwordless login |
| RBAC | Authorization | Role permissions |
| ABAC | Authorization | Attribute permissions |
| ACL | Authorization | Resource permissions |
| Kerberos | Authentication | Enterprise authentication |
Session = Server remembers you JWT = You carry your identity OAuth2 = Permission delegation OIDC = User identity SAML = Enterprise SSO MFA = Extra verification Passkey = Passwordless authentication RBAC = Role permissions ABAC = Attribute permissions ACL = Resource permissions