OpenID Connect

LoginRadius enables seamless integration of your OpenID Connect (OIDC) client with its platform, adhering to standard OpenID Connect specifications.

OpenID Connect 1.0 is a simple identity layer built on the OAuth 2.0 protocol. It allows clients to authenticate end-users by leveraging the Authorization Server's verification process. In addition, it provides access to essential profile details, such as the user's name and email. OpenID Connect simplifies user identity management in web and mobile applications by combining authentication and authorization, delivering secure and seamless user experiences across various platforms.

Note: For non-user-based authorization scenarios—such as server-to-server or machine-to-machine communication—LoginRadius also supports the Client Credentials grant from the OAuth 2.0 specification. This grant type is not part of the OpenID Connect standard as it does not involve user identity, but is supported for M2M integrations.

Use Cases for OpenID Connect (OIDC)

OpenID Connect (OIDC) is a versatile identity layer that enables secure and seamless user authentication and authorization across various applications and platforms. Below are some practical scenarios where OIDC is commonly used:

Single Sign-On (SSO)

• Scenario: A company provides multiple web applications to its users and wants them to log in once to access all applications without re-authenticating.
• How OIDC Helps: OIDC acts as the identity layer on top of OAuth 2.0, enabling users to authenticate with a single set of credentials across different platforms. This enhances user convenience and reduces password fatigue.

Accessing User Profiles

• Scenario: An e-commerce application needs access to a user’s profile details (e.g., name, email, and address) to personalize the shopping experience.
• How OIDC Helps: With OIDC, the app can request access to user profile details securely using standard scopes like openid, profile, and email.

Identity Federation

• Scenario: A university integrates its internal user database with third-party cloud applications for students and staff, enabling them to use their existing credentials for external services.
• How OIDC Helps: OIDC facilitates identity federation by allowing the university to act as an identity provider, securely authenticating users and sharing their identity information with authorized third-party services.

Mobile and Single-Page Applications (SPAs)

• Scenario: A fitness tracking app needs a secure way to authenticate users and access their health data across multiple devices.
• How OIDC Helps: OIDC’s PKCE Flow ensures secure authentication for public clients like mobile apps and SPAs, preventing token interception.

Cross-Platform User Experience

• Scenario: A gaming platform enables users to seamlessly play games on mobile desktops and the web while maintaining their identities across platforms.
• How OIDC Helps: OIDC ensures consistent user identity across multiple devices and platforms, providing a seamless and unified user experience.

OIDC’s flexibility and adherence to standards make it a valuable tool for enhancing security, simplifying authentication, and improving user experiences in various applications.

Configuration

Create the App

1. Navigate to Applications in the Console.
2. Click Add Application.
3. Enter a unique Application Name and click Create Application.

Your app is now created and you will be taken to the app's configuration page.

Configure the App

General

1. Credentials & Security

• Name : The display name for your application.
• Client ID : Auto-generated unique identifier. Used in OIDC authorization requests.
• Client Secret : Auto-generated secret. Authenticates your app at the token endpoint. Never expose this publicly.
• Token Endpoint Auth Method : Defines how your app authenticates when calling the token endpoint.
• Default Workflow : Set the default interaction pattern for this application.

2. Grant Settings

• Grant Type : Select the following for OIDC:

  • Authorization Code : Primary OIDC flow. Returns both an access token and an ID token containing identity claims.
  • Refresh Token : Maintain sessions without requiring users to re-authenticate.

• Scopes : OIDC relies on scopes to include identity claims in the ID token:

  • Profile (required) : Returns name, picture, and profile details.
  • Email address (required) : Returns the user's email address.
  • Phone, Address (optional)

3. MCP Registration (Optional)

• CIMD (Client ID Metadata Document) : Allows your app to use a URL as its identity. The server fetches and verifies client details automatically.
• DCR (Dynamic Client Registration) : Allows external apps to register and obtain credentials at runtime without manual dashboard setup.

Tokens

1. Token & Session Settings

• Access Token Lifetime (secs) : How long the access token remains valid. (Default: 3600)
• Refresh Token Lifetime (secs) : How long the refresh token remains valid. (Default: 86400)
• ID Token Lifetime (secs) : How long the ID token (identity assertion) remains valid.
• Force Reauthentication : When enabled, users must re-authenticate at the authorization server instead of continuing with an existing session.
• Signed User Info : When enabled, user info is returned as a signed JWT token; otherwise returned in JSON format.

Tokens are signed using the RS256 algorithm.

2. Authorization Requests (Optional)

• PAR (Pushed Authorization Request) : Sends authorization requests server-side through the PAR endpoint, keeping request parameters out of the browser URL.
  • Require PAR : Require this app to send all authorization requests through the PAR endpoint.
• RAR (Rich Authorization Request) : Enables fine-grained authorization data in PAR flows. Add the allowed authorization_details.type values for this app.

3. Data Mapping & Metadata (Optional)

• Audiences : Define the intended recipients of the ID token.
• Data Mapping : Attach custom fields or properties to the token data response.
• Metadata : Add static non-profile values to the data response.

Endpoints

1. OIDC Endpoint URLs

Copy these OpenID Connect endpoints for your integration:

• Issuer URL
• Authorization URL
• Device Authorization URL
• Token URL
• User Info URL
• OpenID Discovery Endpoint
• OAuth Authorization Server Metadata
• JWKS URL

2. Redirect & Logout URLs

• Login Redirect URLs : Whitelisted URIs where users are sent after successful authentication.
• Logout Redirect URLs : URIs for post-logout redirection.

If left blank, redirect_uri is validated against the globally configured Domains list in Tenant Settings.

3. Cross-Origin Authentication

• CORS Origin : Whitelist domains allowed to interact with your app's authentication endpoints from the browser.

4. Back-Channel Logout

• Back-Channel Logout : Configure a logout endpoint that LoginRadius will call to ensure users are logged out across all active sessions when a logout event is triggered.

APIs

Select the Audience and Scopes this app is permitted to access. Click + Add New to define API-level access permissions.

MCP Clients

MCP clients connected to this application will be listed here. Use the search bar to find clients by name or client ID.

Connections

Enable Set authentication configuration for this app to configure authentication-level settings specific to this application.

OpenID Connect (OIDC) Flows Overview

OpenID Connect (OIDC) defines three types of authentication flows, each suited for different use cases and application types. Every flow involves interaction with the Authorization Endpoint, where the user is prompted to log in. Below is an overview of these flows:

1. Authorization Code Flow

   Used for server-side web applications where the Client Secret can be securely stored. The authorization code is appended as a query string to the redirect URI.

2. Authorization Code Flow with PKCE

   Suitable for public clients such as mobile apps and SPAs where the Client Secret cannot be securely stored. The authorization code is appended as a query string to the redirect URI.

3. Implicit Flow

   Designed for SPAs where tokens are issued directly to the client without an intermediate authorization code exchange. Tokens are returned in the URI fragment.

4. Hybrid Flow

   Combines the benefits of Authorization Code and Implicit flows, suitable for scenarios requiring immediate token access and additional security. Tokens are returned in the URI fragment.

5. Device Code Flow

   Used for devices with limited input capabilities. The user is prompted to enter a code on a secondary device to authenticate.

Parameter	Required/Optional	Description
client_id	Required	The unique OIDC Client ID.
redirect_uri	Required	URI where the response is sent. Must be whitelisted in the Admin Console. If specified in the OIDC configuration, it takes precedence.
response_type	Required	Specifies the desired processing flow (code, id_token, or combinations for Hybrid Flow).
state	Optional	Recommended for CSRF protection. It helps maintain the state between the request and callback.
scope	Required	A space-delimited list of requested scopes (e.g., openid, profile, email). Must include openid for OIDC.
nonce	Optional	Token validation parameter to prevent replay attacks. Included in the ID Token if provided.
response_mode	Optional	Specifies how the response parameters are returned. Values: query, fragment, or form_post. The default depends on the flow.
ui_locales	Optional	Preferred languages for the user interface, e.g., "en-US fr-CA"
display	Optional	How the login page is displayed. Values: page (default), popup.
prompt	Optional	Specifies reauthentication and consent behavior. Values: login, none.
Claims	Optional	JSON object specifying claims requested in the ID Token or UserInfo response. Example: { "id_token": { "email": null }, "userinfo": { "name": null } }.
id_token_hint	Optional	A previously issued ID Token as a hint about the user's session returns login_required if the user is not authenticated.
login_hint	Optional	A hint for the Authorization Server about the login identifier (e.g., email or phone).
max_age	Optional	Maximum allowable time (in seconds) since the last user authentication. Forces reauthentication if exceeded.
acr_values	Optional	Specifies the authentication context class reference. For example, loginradius:nist:level:1:re-auth forces reauthentication.

Response Modes

1. Query: Parameters are appended as a query string in the redirect_uri.
   Example: https://example.com?state=abc&code=xyz
2. Fragment: Parameters are appended as a URI fragment.
   Example: https://example.com\#state=abc&code=xyz
3. Form Post: Parameters are sent as a POST request to the redirect_uri.

Flow	Default Response Mode
Authorization Code Flow	query
Implicit Flow	fragment
Hybrid Flow	fragment

You can leverage OIDC for secure and scalable authentication across your applications by selecting the appropriate flow and configuring the parameters accordingly.

Audience-Restricted Tokens (Resource Indicators)

LoginRadius accepts the RFC 8707 resource parameter on OIDC /authorize and /token requests, binding each issued access token to a specific API audience. This works in tandem with the Audiences app-configuration field above. See Resource Indicators for the full guide.