13 docs tagged with "pkce"

OAuth2/OIDC application types (client_type values), recommended flows, and configuration availability by type in cidaas.

General

The Authentication to cidaas follows a sequential flow with three main steps. This documentation explains how to implement the complete authentication process.

The Authorization Code Flow is one of the OAuth2 flows that was designed to securely authenticate a user and issue an access token. The basic concept behind the authorization code flow is that a code is issued after identification and this must be exchanged for an access token.

The Client Credentials Grant is a type of OAuth 2.0 flow that allows a client application to request access tokens directly from an authorization server by using its own credentials. This flow is specifically designed for Machine-to-Machine (M2M) authentication scenarios where no user interaction is required.

Benefits

The Device Code Flow (officially: OAuth 2.0 Device Authorization Grant) is an OAuth 2.0 grant type designed for devices that don't have a browser or have limited input capabilities, such as smart TVs, gaming consoles, CLI tools, or IoT devices. It enables users to authorize these devices to access their resources by authenticating on a separate device (e.g., smartphone or computer) with a full browser.

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.

The Authorization Code Flow with PKCE (Proof Key for Code Exchange) is an extension of the Authorization Code Flow. It is specifically designed to authenticate native or mobile application users, but is recommended for all scenarios where user authentication is required, especially for public clients that cannot securely store a client_secret.

Implementing the Pushed Authorization Request (PAR) Flow

Session management lets users stay signed in across applications and devices. This guide explains how sessions relate to OAuth 2.0 and OpenID Connect in cidaas, and points you to the right flows for validation, logout, and native-to-web handoff.

Native applications (for example mobile apps) often open company-owned web applications in the system browser: centralized profiles, webshops, help portals, and similar. Those sites typically expect an active IdP session in the browser—the same kind of session that powers Single Sign-On (SSO) for pure web apps—not only a token inside the native app.

Configure and customize the welcome user email sent after successful registration.