1. OpenID Connect (OIDC)
- An identity layer built on top of OAuth 2.0.
- Provides authentication and basic profile information.
- Relies on ID tokens (JWT format).
2. Single Sign-On (SSO)
- A user logs in once to access multiple applications.
- Centralized authentication handled by an Identity Provider (IdP).
- Examples: Google SSO, Microsoft Azure AD.
3. OAuth 2.0
- An authorization framework (not for authentication).
- Grants access to resources without sharing user credentials.
- Uses access tokens to secure API calls.
4. Auth0
- A cloud-based Identity as a Service (IDaaS) platform.
- Supports OAuth 2.0, OIDC, and SAML.
- Provides features like user management, MFA, and social login.
5. Identity Providers (IdP)
- Services that manage user identity.
- Examples: Keycloak, Okta, Azure AD, Ping Identity.
6. SAML (Security Assertion Markup Language)
- XML-based protocol for exchanging authentication data.
- Often used in enterprise SSO solutions.
7. JWT (JSON Web Token)
- A compact, URL-safe token format.
- Contains claims (identity, permissions) encoded in three parts: header, payload, signature.
OAuth 2.0 Flows
| Flow | Use Case | Steps | Key Token |
|---|---|---|---|
| Authorization Code | User-based web app authentication (most secure). | 1. Redirect user to authorize. 2. Exchange authorization code for tokens. |
Access, Refresh, ID |
| PKCE (Proof Key for Code Exchange) | Secure mobile/SPA variant of Authorization Code. | 1. Generate a code verifier & challenge. 2. Send verifier in token exchange. |
Access, Refresh, ID |
| Implicit | SPAs needing quick tokens (legacy, less secure). | 1. Directly return tokens in the URL fragment after user consent. | Access, ID |
| Client Credentials | Machine-to-machine communication (no user interaction). | 1. Application sends client ID & secret directly. | Access |
| Resource Owner Password | Direct user credentials exchange (legacy, avoid). | 1. Application sends user credentials to the authorization server to get tokens. | Access, Refresh |
| Device Code | Devices without browsers (e.g., TVs, IoT). | 1. Show user a code & URL. 2. User authorizes on another device. |
Access, Refresh |
OIDC Flows
OIDC builds on OAuth 2.0 by adding ID tokens for authentication.
| Flow | Additional Steps for OIDC |
|---|---|
| Authorization Code | ID token is included in the response to identify the user. |
| Implicit | Returns both Access & ID tokens directly. |
| Hybrid | Returns both Authorization Code & ID token in the first response. |
Key Tokens
| Token | Purpose | Format | Expiry |
|---|---|---|---|
| Access | Authorize API access. | JWT (OAuth 2.0 spec compliant) | Short-lived (minutes). |
| ID | User authentication & profile claims (OIDC). | JWT | Short-lived (minutes). |
| Refresh | Obtain new access tokens without re-authenticating. | Opaque or JWT | Long-lived (days/months). |
Key Concepts Cheat Sheet
| Concept | Description |
|---|---|
| Redirect URI | Callback URL where tokens/codes are sent after user authorization. |
| Scopes | Permissions requested by the client application (e.g., profile, email). |
| Consent Screen | UI presented to users to approve access scopes requested by the app. |
| PKCE | Adds a layer of security to prevent interception of authorization codes. |
| Well-Known URL | Discovery endpoint (/.well-known/openid-configuration) for fetching IdP metadata. |
| MFA | Multi-factor authentication for added security (e.g., SMS, authenticator apps). |
Quick Decision Guide
| Scenario | Flow to Use |
|---|---|
| Secure user authentication (web app) | Authorization Code + PKCE |
| SPA with no backend | PKCE (replaces Implicit flow) |
| Machine-to-machine API access | Client Credentials |
| Devices without browsers | Device Code |
| Avoid (legacy, insecure, or risky scenarios) | Implicit, Resource Owner Password |
Comparison of Access Control Models
| Feature | Context-Based Access Control (CBAC) | Role-Based Access Control (RBAC) | Fine-Grained Access Control (FGAC) | Discretionary Access Control (DAC) | Mandatory Access Control (MAC) |
|---|---|---|---|---|---|
| Decision Basis | Real-time contextual attributes like time, location, device, and user behavior. | Predefined roles and associated permissions. | Highly detailed policies based on specific attributes. | Owner or creator defines access permissions. | Central authority enforces access based on labels. |
| Flexibility | Highly flexible and adapts to environmental changes. | Limited to static or hierarchical roles. | Extremely flexible; designed for complex needs. | Flexible but depends on owner decisions. | Rigid and predefined, based on strict rules. |
| Granularity | Medium to High: Uses multiple contextual factors. | Medium: Permissions tied to roles, not specific attributes. | Very High: Can specify access at a granular level. | Low to Medium: Based on owner's definition. | High: Broad classification levels control access. |
| Adaptability | High: Evaluates access dynamically based on real-time context. | Low: Static, predefined roles rarely change dynamically. | High: Highly customizable for complex needs. | Medium: Relies on owner's decisions. | Low: Cannot adapt dynamically. |
| Security | Very High: Mitigates risks with dynamic evaluation. | Medium: Static roles can lead to privilege creep. | Very High: Fine-grained policies reduce over-permissioning. | Medium: Risks due to inconsistent permissions. | Very High: Strict rules prevent unauthorized access. |
| Ease of Implementation | Medium: Requires infrastructure for monitoring context. | Easy: Widely supported and simple to implement. | Complex: Requires detailed policy definitions. | Easy: Straightforward implementation. | Difficult: Strict classification and enforcement. |
| Scalability | High: Scales well in dynamic environments. | High: Scales well with role hierarchies. | High: Suitable for large systems with diverse requirements. | Low: Limited to individual owners. | Low: Difficult to scale due to rigid structure. |
| Use Cases | - Remote work environments. | - Enterprise applications. | - Multi-tenant systems. | - Small teams or personal systems. | - Military and government systems. |
| - Banking transactions. | - Basic organizational hierarchies. | - Healthcare and finance. | - File-sharing applications. | - Classified data protection. | |
| - Zero Trust security models. | - Traditional IT. | - GDPR-compliant systems. |
Which Model to Use?
| Scenario | Recommended Model |
|---|---|
| Flexible, real-time access control needed | CBAC |
| Structured, role-based organizations | RBAC |
| High compliance and precision requirements | FGAC |
| Small-scale or personal systems | DAC |
| Military or highly sensitive environments | MAC |
Top comments (0)