Authentication and Authorization

General

cidaas provides numerous mechanisms for you to achieve Authentication and Authorization of your application resources. In addition, numerous APIs are provided that are compliant with OAuth 2.0/2.1 and OpenID Connect (OIDC). OpenID Connect (OIDC) is indeed an extension of OAuth 2.0. The OAuth 2.0 protocol provides API security via scoped access tokens, and OpenID Connect provides user authentication and single sign-on (SSO) functionality.

In summary, when you use OpenID Connect, you get the benefits of OAuth 2.0 for secure delegated access, plus the additional features needed for user authentication and obtaining user information.

cidaas simplifies and removes the need for your Application to collect or store a user's credentials, thus reducing the risks of data leaks or misuse. While it's best to understand the OAuth RFC and OpenID RFC, a brief description is presented here for you to understand a typical Authorization flow.

Key Elements and Concepts

• Client: This is your application that interacts with the end-user and needs to access resources owned by the end-user (resource owner). You need to create your client in cidaas by adding a new App in App Management
• Resource Owner: Typically the end-user of your application, who owns information (like a Name, Photo etc).
• Resource Server: Server that hosts protected information securely.
• Authorization Server: The server that issues Access Tokens to client after successful authentication of resource owner and obtaining authorization from resource owner. In your case it is cidaas 😉
• Authorization Grant : A credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token. The OAuth 2.0 Authorization Framework defines four standard grant types, namely, authorization code, implicit, resource owner password credentials, and client credentials.
• Authorization Code : A temporary code that the client will exchange for an access token. This code is sent to the redirect URI that was specified in the Authz-Endpoint. (Read more about Authorization Code Flow and PKCE Flow)
• Client Credentials: This grant type is used by clients to obtain an access token outside of the context of a user. Clients typically use this to access resources about themselves rather than to access a user's resources. Read more about Client Credentials Flow
• Access Token : An access token is a string that applications use to authorize a request. The access token represents the authorization of a specific application to access specific parts of the data. There is no specific format for an access token. As far as the client application is concerned, the access token is an opaque string. In cidaas it is a JWT-Token where claims are added. Access tokens must be kept confidential in transit and in storage. The only parties that should ever see the access token are the application itself, the authorization server, and resource server. The token endpoint is where apps make a request to get an access token for a user.
• Refresh Token : For security purposes, access tokens may be valid for a short amount of time. Once they expire, client applications can use a refresh token to "refresh" the access token. This credential artifact lets a client application get new access tokens without having to ask the user to log in again.

OAuth2 Flow per Client Type

The choice of OAuth2 flow depends on your client type and security requirements. Below is a comprehensive guide to help you select the appropriate flow for your use case.

Client Types and Device Categories

Client Type	Device Examples	Grant Type	Authentication Type	Key Characteristics
Web Applications	Single Page Apps (SPA), Traditional Web Apps	authorization_code with PKCE, refresh_token	User Authentication	Requires HTTPS redirect URIs. Can securely store tokens in backend or use PKCE for public clients.
Mobile Applications	Android, iOS, Windows Mobile Apps	authorization_code with PKCE, refresh_token	User Authentication	Supports custom URI schemes (e.g., myapp://callback) or localhost for development. No client secret required with PKCE.
IoT & Limited Input Devices	Smart TVs, Gaming Consoles, IoT Devices	urn:ietf:params:oauth:grant-type:device_code	User Authentication	Devices with limited input capabilities. Uses QR codes or user codes for authentication on a separate device.
Server-to-Server (M2M)	Backend Services, Microservices, APIs	client_credentials	Machine Authentication	No user interaction required. Secure storage of client credentials. Ideal for API-to-API communication.
Third-Party Applications	External Integrations, Partner Apps	authorization_code with PKCE, refresh_token	User Authentication	Requires user consent for data access. First-time authentication prompts for consent.

Detailed Flow Differences

User Authentication Flows (Require User Interaction)

Authorization Code Flow (with Client Secret)

• Use Case: Traditional web applications with a secure backend
• Security: Requires client_secret stored securely on the server
• Flow: User authenticates → Authorization code issued → Code exchanged for token using client_secret
• Best For: Server-side web applications where the backend can securely store credentials

Authorization Code Flow with PKCE (Recommended)

• Use Case: Single Page Apps (SPAs), Mobile Apps, Public Clients
• Security: No client_secret required. Uses code_verifier and code_challenge to prevent authorization code interception
• Flow: Client generates code_verifier → Creates code_challenge → User authenticates → Code exchanged with code_verifier
• Best For: Public clients where storing secrets is not secure (mobile apps, SPAs)

Pushed Authorization Request (PAR)

• Use Case: Enhanced security for authorization requests, especially with complex parameters
• Security: Avoids long URLs, reduces exposure of sensitive parameters, enables better logging and audit trails
• Flow: Client pushes authorization parameters → Server returns request_uri → Client uses request_uri in authorization endpoint
• Best For: Applications requiring enhanced security, complex authorization requests, or better audit capabilities
• Compatible With: Authorization Code Flow and PKCE Flow
• Learn More: PAR Documentation

Device Code Flow

• Use Case: Devices with limited input capabilities (Smart TVs, IoT devices)
• Security: User authenticates on a separate device (smartphone/computer)
• Flow: Device requests authorization → User code displayed → User authenticates on separate device → Device polls for token
• Best For: Smart TVs, gaming consoles, IoT devices without keyboards

Machine-to-Machine (M2M) Authentication Flow

Client Credentials Flow

• Use Case: Server-to-server communication, API-to-API calls, backend services
• Security: Uses client_id and client_secret for authentication. No user context required
• Flow: Client sends credentials → Token issued directly → Token used for API access
• Best For: Microservices, scheduled jobs, backend integrations
• Security Considerations:
  • Store client_secret securely (use environment variables, secret management systems)
  • Use short-lived tokens with appropriate expiration times
  • Implement token introspection for validation
  • Scope tokens to minimum required permissions
  • Monitor and log all token requests for security auditing

Choosing the Right Flow

For User-Facing Applications:

• Web Apps with Backend: Use Authorization Code Flow (with client_secret)
• SPAs or Mobile Apps: Use Authorization Code Flow with PKCE (no client_secret)
• Enhanced Security: Use Pushed Authorization Request (PAR) with Authorization Code or PKCE flows
• IoT/Limited Input Devices: Use Device Code Flow

For Backend Services:

• API-to-API Communication: Use Client Credentials Flow
• Microservices: Use Client Credentials Flow with appropriate scopes
• Scheduled Jobs: Use Client Credentials Flow

Overview about OAuth2 Flows

The OAuth2 Flow Charts and where to use which flow you can also find in Standard Flows.

Flow Name	Grant Type	When to Use this Flow
Client Credentials	client_credentials	This grant type is used for server-to-server communication (m2m) or when the client application is acting on its own behalf.
Authorization Code / PKCE	authorization_code	This grant type is used for web applications and mobile apps, where the application wants to access protected resources on the user's behalf (user authentication).
Pushed Authorization Request (PAR)	authorization_code (with PAR)	This extension (RFC 9126) enhances security by pushing authorization parameters to the server instead of including them in URLs. Works with Authorization Code and PKCE flows. Learn more
deprecated Password	password	This grant type is used when the client application has a high degree of trust with the authorization server. (not recommended)
deprecated Implicit	token	This grant type is used in applications where the application wants to access protected resources on the user's behalf (user authentication). (not recommended)
Refresh	refresh_token	This grant type is typically used when an access token has expired or is about to expire and the client application needs to obtain a fresh access token to continue accessing protected resources
Device Code	urn:ietf:params:oauth:grant-type:device_code	This grant type is typically used for devices that have limited input capabilities, such as smart TVs, gaming consoles, and Internet of Things (IoT) devices

Benefits of Authorization with cidaas

• Using cidaas for authorization retains all of your user information and grant user tokens to control their authorization and authentication.

• Standardization with the OAuth and OIDC protocols makes it easy to work with any type of application because of their universal implementation and properties.

• Effortlessly perform Single Sign-On (SSO) with cidaas for your OpenID Connect apps. You can also secure your own APIs and provide user authorization to access your web services.

• cidaas allows you to customize Authorization to protect your own resource servers, define your own custom OAuth 2.0 scopes, claims, and access policies to support authorization for your APIs.

• Transparent data interchange using Readable JSON Format.

• cidaas provides robust API access via OAuth which provides better visibility on who has logged in and at what access level.

Capabilities

• SSO with OpenID Connect.
• Use cidaas Developer SDKs & Widgets for SSO.
• Retrieve user profile in ID Token.
• Apply authorization policies to custom APIs.
• Add custom scopes or claims to tokens.

Need Support?

Please contact us directly on our support page.