Overview

The Maverics Orchestrator can be configured to act as an OpenID Connect (OIDC) Provider, exposing standard endpoints for token issuance and user authentication. This allows modern applications to delegate authentication to Maverics, which in turn orchestrates identity across one or more upstream IDPs. Applications authenticate using standard OIDC protocols, while Maverics handles policy enforcement, claim generation, and IDP abstraction.

Supported OIDC Grant Types

authorization_code – For web and mobile apps using front/back-channel token exchange
client_credentials – For non-user service-to-service authentication
refresh_token – To obtain new access tokens without re-authenticating
password – Enables resource owner password credentials grant (typically for testing or tightly scoped trusted clients)

The password grant type enables the Resource Owner Password Credential Grant as defined in RFC 6749 Section 4.3 flow. Since this flow handles user’s credentials it must be used with highly-trusted clients.
Additional security considerations are documented in RFC 6819 Section 4.4.3.
⚠️ Strata does NOT recommend using the ROPC flow.

implicit_id – Returns an ID token directly from the authorization endpoint (legacy)
implicit_token – Returns an access token directly (legacy)

The implicit_id and implicit_token grant types are used for supporting the Implicit Flow with id_token and access_token respectively returned from the authorization endpoint.
⚠️ Strata does NOT recommend using the implicit flow.
When combined with authorization_code grant type they can be used to implement the Hybrid Flow.

Proof Key for Code Exchange (PKCE)

The OIDC Provider supports Proof Key for Code Exchange (PKCE) for all OIDC apps using the authorization_code grant type - no additional configuration is required. This mechanism is used to mitigate the risk of authorization code interception attacks.

Clients that use PKCE include the code_challenge and code_challenge_method parameters in the authorize request. Currently, the Orchestrator only supports the S256 code challenge method. In the subsequent token request, the client must present the code_verifier which is validated against the original challenge.

PKCE is required for public clients, however it can be bypassed for legacy apps that do not support PKCE when using the Authorization Code grant type.

Per OAuth 2.0 Security Best Current Practice, public clients MUST use PKCE when using the Authorization Code grant type. The Bypass PKCE option should only be used for legacy apps that are unable to use PKCE. Avoid using this configuration unless absolutely necessary.

Scopes and claims returned

Maverics issues ID tokens and supports the UserInfo endpoint, with claims drawn from attribute providers and policy configuration.

Scope	Claims Returned
openid	sub
profile	name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, updated_at
email	email, email_verified
phone	phone_number, phone_number_verified
offline_access	Enables issuance of a refresh_token (no additional claims; affects token behavior)

Custom claims can be added or transformed via user flow policies and service extensions.

This guide provides an overview of the following topics:

Prerequisites

Completed the Maverics Storage Configuration Guide

Define services to include in your Identity Fabric

You can choose identity or attribute providers to include in your Identity Fabric. Leveraging services from cloud based IDPs such as Microsoft Entra ID, Okta, Auth0, and Ping, open source providers such as Keycloak or WS02, and on prem services like LDAP, ensures that your application has what it needs for a secure authentication and authorization user flow. For providers not on the list, Maverics supports generic SAML and OIDC connections.

From your IDP, you will need to register a new application. From Maverics, you will create a new identity fabric configuration. You can then use it in a user flow for authentication.

If you need to use another identity service like an LDAP directory, you can string them together with a username mapping, allowing you to use extended attributes for claims or authorization rules.

You can also use these providers in Service Extensions when building custom Authentication flows or dynamically loading or transforming attributes.

The following steps use the Strata provided Keycloak IDP:

Go to Identity Fabric
On the right, scroll and select Keycloak (OIDC)
Click to enlarge

For the OIDC configuration, enter the following:

Name	Description	Field
Name	A unique identifier for the connector configuration. This cannot be changed once it is set.	mavericsOIDC
OIDC Well Known URL	The URL that returns OpenID Connect metadata about the OIDC authorization server.	https://keycloak.strata-eval.io/realms/maverics/.well-known/openid-configuration
OAuth Client ID	The OAuth client ID registered with the OIDC provider.	mavericsclient
OAuth Client Secret	The OAuth client secret associated with the client ID.	mavericsclientsecret
Redirect URL(s)	A list of allowed redirect URIs for the login flow.	https://localhost:8443/oidc
Logout Callback URL(s)	A list of allowed redirect URIs for the logout flow.	https://localhost:8443/oidc/logout
Allowed Audiences	Optional configuration that represents a list of audiences that are allowed to consume access tokens. When a client makes a request to the authorization endpoint, an optional resource parameter can be included that indicates the target audience of the token. The value provided in the resource parameter must be on the list of allowed audiences. This configuration is used when resource servers, such as APIs, authorize via the access token. For more information, please reference RFC 9068.	https://example.com client api://resource-server
Scopes	A space-delimited string specifying the scopes to request during authentication.	openid profile email
Proof Key for Code Exchange (PKCE)	Enable or disable Proof Key for Code Exchange (PKCE).	Enabled

Deploy an OIDC provider

From the Deployments Manager go the Orchestrator Settings section to define the endpoints, user info service extension and JWKs signing options for your OIDC provider.

Enter the issuer URL, and click Generate to automatically fill out the standard endpoints. You can override with custom values at any point.

OIDC Provider Options

Field / Endpoint	Description
Issuer	The domain to which tokens will be attributed. It must be a case-sensitive URL (using HTTPS), including host and optional port, without query or fragment components. It must match the iss claim in tokens.
Well-Known	/.well-known/openid-configuration endpoint for OIDC metadata discovery. Clients use it to discover supported endpoints and algorithms. This corresponds to OpenID Connect Discovery 1.0, section 3.
Authorization	OAuth 2.0 Authorization Endpoint: used by clients to initiate authentication requests. This corresponds to OpenID Connect Core 1.0, section 3.1.2.
Token	OAuth 2.0 Token Endpoint: used by clients to exchange authorization codes for tokens. This corresponds to OpenID Connect Core 1.0, section 3.1.3.
Introspect	Used to validate and retrieve metadata about access tokens. This corresponds to OAuth 2.0 Token Introspection, RFC 7662.
Revocation	Used to revoke specific refresh or access tokens. This corresponds to RFC 7009, section 2.
End Session	RP-initiated logout endpoint. Allows clients to end the user session. This corresponds to the OpenID Connect RP-Initiated Logout RFC.
User Info	The endpoint where the OIDC Provider will return claims about the authenticated end user. If available, it will return claims associated with any of the following scopes: profile, openid, phone, email and address. If Claims have been defined for the corresponding OIDC application’s user flow, those mappings will be applied to the userinfo response. Refer to the Scopes and claims returned table for mapping options. This corresponds to OpenID Connect Core 1.0, section 5.3. How scopes relate to claims is defined in OpenID Connect Core 1.0, section 5.4.
User Info Claims Extension Optional	Allows a Service Extension to customize claims in the user info response. Uses session attributes provided in the policy.
JWKS (JSON Web Keys)	Returns the JWKS document that includes public keys used to sign and verify JWTs. Clients fetch keys from this endpoint to verify token signatures. This corresponds to RFC 7517: JSON Web Key (JWK).
Private Keys	Displays the private key used to sign tokens. Click Edit Generate - Maverics will generate a private key that can be used to sign tokens. After you Save your OIDC settings it will generate a private key. Upload - a PEM encoded private key. Secret Provider - Maverics can fetch sensitive information from a Secret Provider. Enter the key surrounded by brackets <>.
Redis Cache Optional	Specifies an external Redis cache to be used for token/session storage. If unset, the default in-memory cache is used.
Session Correlation	This is an optional field used to correlate back-channel token requests with the resource owner’s session. This correlation allows for tracking an authorization code flow login transaction across both the authorization endpoint and token endpoint. Please note that session ID logging will only occur at the token endpoint when this toggle is turned on and session ID logging is enabled.

Configure an OIDC application

From the Applications page, create an OIDC app by selecting OIDC-based under Application Types.

Configuration settings for OIDC application including grant types and redirect URLs. — Click to enlarge

Field Name	Description	Example
Name	A friendly name for your OIDC application.	ExampleApp
App Icon	Upload an image for your application to display in Maverics.	Maverics supports JPEG, PNG, or SVG, up to 2MB maximum.
Public	Defines that an OIDC app is a public client. Public clients, such as SPAs and native applications, cannot securely store authentication credentials. Therefore, public clients support a limited set of grant types, namely: authorization_code refresh_token implicit_id implicit_token When using the authorization_code grant, public clients must use PKCE. Public clients cannot use flows that require a client secret, such as client_credentials or password.
Grant Types	Select one or more grant types. Client Credentials Authorization Code Refresh Token Password The password grant type enables the Resource Owner Password Credential Grant as defined in the RFC 6749 Section 4.3 flow. Since this flow handles user’s credentials it must be used only with highly-trusted clients. Strata does NOT recommend using the ROPC flow. Additional security considerations are documented in RFC 6819 Section 4.4.3.
Demonstrating Proof of Possession (DPoP)	Enable to provide sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. Once DPoP is enabled, opaque nonces are also enabled. The nonce ensures the maximum age of the DPoP proof. When enabled, DPoP proof headers are required to include a nonce claim, per the RFC. Orchestrator clients should expect a 400 response with the error use_dpop_nonce when the nonce is missing from the DPoP proof. The current nonce is obtained by reading the DPoP-Nonce HTTP header in the same 400 response. For more information on on DPoP for OIDC applications, refer to RFC 9449.
Client ID	The client ID OIDC clients will need to connect.	`<CLIENT_KEY>`
Client Secret	The client secret OIDC clients will need to connect.	`<SECRET_KEY>`
Redirect URL	The allow list of URLs to redirect to your clients.
Access Token Settings: Type	The type can be set to either jwt (default) or opaque.	jwt
Access Token Settings: Length	If the type is set to opaque, the length can be set to between 22 and 256 characters. If jwt, the default length is 28 characters.	28
Access Token Settings: Lifetime Seconds	By default, access tokens have a lifetime of one hour. You can configure each client’s Access Token lifetime, by setting the lifetimeSeconds tag under accessToken section, to a valid seconds (integer) value.	30
Refresh Tokens	The Refresh Tokens field defines the configuration for the OAuth refresh token. Refresh tokens are used to get a new access token without user interaction. Refresh tokens are automatically rotated with every access token refresh. That is, every time a refresh token is used to generate a new access token, a new refresh token is also returned. If a previously issued refresh token is reused outside an acceptable window, the active refresh token will be invalidated. Refresh tokens are rotated to protect against refresh token replay attacks and compromised long-lived refresh tokens. For more information, please reference the OAuth Security Topics RFC.
Refresh Token Settings: Allow Offline Access	Defines whether a client can request refresh tokens. Refresh tokens will only be issued if the with this enabled and the authorization request includes the offline_access scope. If Grant Types are defined, refresh_token must be specified for refresh tokens to be issued. See Grant Types for more info.
Refresh Token Settings: Length	Can be set to between 22 and 256 characters to define the length of a refresh token.	22

Configure the user flow

From main navigation, click User Flows, and click New. Enter a name for the user flow and select the OIDC application. Click Create.

Field	Description
Name	Name of the user flow
Application	The applications associated with the user flow. Tip: User Flows as Policy Templates OIDC can be used for multiple applications and an application can only be associated with one user flow. This is especially useful when you want a group of apps to share the same authentication provider, authorization policy and user experience.
Authentication	You can select a configured identity provider, a continuity strategy, or Authentication service extension.
Access Token Service Extension	Use a Custom Claims service extension that can customize how claims in the access token are built. This service extension should be used when non-standard claims need to be added to the access token.
ID Token Service Extension	Use a Custom Claims service extension to customize how claims in the ID token are built. This service extension should be used when non-standard claims need to be added to the ID token.
Attribute Provider	Define attribute provider to use as a source for claims or within authorization rules. Options Select an attribute provider, choose the identity provider you used in the Authentication setup, and select a claim that will be on the session that you will use to look up the user in the attribute provider. Select a Load Attributes service extension to to customize how the loading of attributes is done. This extension is often used to load attributes from proprietary data sources such as enterprise APIs.
Authorization	Define access control rules for the applications Options Allow all access - the user is allowed access upon a successful token exchange Use Rules - define conditions for allowing access. See more about Using Rules Authorization service extension - if you have defined an authorization service extension you can select it here.
Claims	Map attributes on a user’s session to claims on the ID token. The claims added to the ID token are determined by the value of the scope parameter sent in the authorization request. The scopes supported, in addition to the required openid scope are email, profile, address and phone. The mapping of claim values to a scope is listed in OpenID Connect Core 1.0, section 5.4. For example, consider an authorization request where the openid and email scopes are requested. Assuming a correct claims mapping, the ID token would include a sub claim, email claim, and email_verified claim. Returning a nonce provided in the authorization request via a claim in the ID token response is supported as well.

Using Rules

Rules rules define a list of access control conditions. All rules must evaluate to true in order user to get access to a given app.

Under Authorization select use Rules to define access.
Choose All (and) or Any (or) to set the operator for the matching conditions.
Choose the Provider to source the attribute. You can choose an identity provider, attribute provider, service extension, or HTTP Request header.
Choose the attribute you will use to evaluate access.
Set the condition (contains, does not contain, equals, or does not equal).
Choose the value of the attribute.
Click Add Rule
Optionally you can add more conditions and more rules.

Deploying the application

Deployments Overview

Deployments in Maverics are how you bundle and publish your orchestration configurations — including applications, user flows, identity services, and policy logic — to your orchestrators for enforcement. Before deploying, review the Deployment Overview to understand how environments, services, and storage work together in Maverics.

Prerequisite: Storage Configuration connected to a Orchestrator service

To successfully deploy and test your application’s user flow, you must first configure a storage storage provider and connect it to installed orchestrator services.

Recommended: Use Maverics Storage for the fastest and simplest evaluation experience.
Other storage options (for example, AWS S3, Google Cloud Storage, Github repo, and Microsoft Azure Blob storage) are supported. See the full Storage Configuration Guides for setup instructions.

Add your application to a deployment

Once your storage is configured, you can deploy your application using the Deployment Manager:

Navigate to Deployments in the Maverics UI.
Create a new deployment or select an existing one.
Add your application(s) to the deployment:
Click Publish Preview to review and validate the deployment configuration.
After confirming the preview looks correct, click Publish to push the configuration to your orchestrators.

Tutorial: Offline Capability in Entra ID and OIDC Fabric