OAuth2 Flows
cidaas leverages a variety of world-class authentication flows to ensure the utmost safety and security of your information. Below is an overview of the OAuth flows available in cidaas, with detailed comparisons to help you choose the right flow for your use case.
Available OAuth2 Flows
| Flow | Description | Link | Client Type | User Interaction |
|---|---|---|---|---|
| Authorization Code Flow | Used for apps that can securely store client secrets (e.g., server-side web apps). Requires client_secret for token exchange. | More Info | Server-side clients (confidential) | Required |
| PKCE (Proof Key for Code Exchange) | A variant of the Authorization Code Flow for public clients, like single-page apps or mobile apps, without requiring a client secret. Uses cryptographic challenge to prevent code interception. | More Info | Public clients (SPAs, mobile apps) | Required |
| Pushed Authorization Request (PAR) | An OAuth 2.0 extension (RFC 9126) that enhances security by pushing authorization parameters to the server instead of including them in URLs. Works with Authorization Code and PKCE flows. | More Info | All client types (works with Authorization Code and PKCE) | Required |
| Client Credentials | Used for server-to-server (M2M) communication where the client is trusted and acts on its own behalf. No user interaction required. | More Info | Confidential clients (backend services) | Not required |
| Device Code Flow | Designed for devices with limited input capabilities (e.g., TVs, IoT devices), allowing users to authenticate via a browser on another device. | More Info | Public clients (IoT, devices) | Required (on separate device) |
| Token Exchange | Exchanges one token for another, often used in delegation scenarios or within microservices. | More Info | Confidential clients (backend services) | Not required |
Key Differences Between Flows
User Authentication Flows vs. Machine Authentication
User Authentication Flows (require user interaction):
- Authorization Code Flow: Traditional flow for web apps with secure backend
- PKCE Flow: Modern, secure flow for public clients (SPAs, mobile apps)
- Pushed Authorization Request (PAR): Enhanced security extension that works with Authorization Code and PKCE flows
- Device Code Flow: For devices with limited input capabilities
Machine Authentication Flows (no user interaction):
- Client Credentials Flow: For server-to-server communication (M2M)
- Token Exchange: For token delegation in microservices
Security Comparison
| Flow | Client Secret Required | Code Interception Protection | Recommended For |
|---|---|---|---|
| Authorization Code | ✅ Yes | ⚠️ Limited (relies on HTTPS) | Server-side web apps |
| PKCE | ❌ No | ✅ Yes (cryptographic challenge) | SPAs, mobile apps |
| PAR | Depends on base flow | ✅ Yes (avoids URL exposure) | Enhanced security for any Authorization Code/PKCE flow |
| Client Credentials | ✅ Yes | ✅ N/A (direct token request) | M2M communication |
| Device Code | ❌ No | ✅ Yes (separate device auth) | IoT, limited input devices |
| Token Exchange | ✅ Yes | ✅ N/A (token-to-token exchange) | Microservices, token delegation |
When to Use Which Flow
Choose Authorization Code Flow if:
- You have a traditional web application with a secure backend
- You can securely store the
client_secreton your server - Your application runs entirely server-side
Choose PKCE Flow if:
- You're building a Single Page Application (SPA)
- You're developing a mobile application (iOS, Android)
- You cannot securely store a
client_secret(public client) - You want the highest security for public clients
Choose PAR (Pushed Authorization Request) if:
- You want enhanced security by avoiding long URLs with sensitive parameters
- You need better logging and audit trails for authorization requests
- You're working with complex authorization requests with many parameters
- You want to reduce exposure of authorization parameters in URLs
- Note: PAR works with both Authorization Code and PKCE flows
Choose Client Credentials Flow if:
- You need server-to-server (M2M) communication
- No user interaction is required
- You're building microservices or API integrations
- You need to secure backend-to-backend communication
Choose Device Code Flow if:
- Your device has limited input capabilities (no keyboard)
- Users can authenticate on a separate device (smartphone, computer)
- You're building for Smart TVs, gaming consoles, or IoT devices
Choose Token Exchange if:
- You need to exchange one token for another (e.g., access token for a different scoped token)
- You're working with microservices and need token delegation
- You need to transform tokens for different services or contexts
- You're implementing a backend-for-frontend (BFF) pattern
Refresh Tokens
Refresh Tokens are not a separate flow, but rather a mechanism used with Authorization Code and PKCE flows. They allow you to obtain new access tokens without requiring the user to re-authenticate. Refresh tokens are typically issued along with access tokens and can be used to request new access tokens when the current one expires.
- Used with: Authorization Code Flow, PKCE Flow
- Purpose: Maintain user sessions without repeated authentication
- Security: Refresh tokens should be stored securely and have longer lifetimes than access tokens
Related Documentation
- OAuth2 Basics - Learn about OAuth2 concepts and terminology
- Access Token / ID Token Claims - Understand token structure and claims
Need Support?
Please contact us directly on our support page.