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.
.png?sv=2022-11-02&spr=https&st=2025-05-05T14%3A52%3A28Z&se=2025-05-05T15%3A12%3A28Z&sr=c&sp=r&sig=4cb2Q8ysPabCMd76vL8DKnI8JpveeHgNT%2BbBAftyaWU%3D)
Click to enlarge
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.Your content goes here
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.
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_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 asMicrosoft Entra ID,Okta,Auth0, and Ping, open source providers such asKeycloakorWS02, and on prem services likeLDAP, 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:
.png?sv=2022-11-02&spr=https&st=2025-05-05T14%3A52%3A28Z&se=2025-05-05T15%3A12%3A28Z&sr=c&sp=r&sig=4cb2Q8ysPabCMd76vL8DKnI8JpveeHgNT%2BbBAftyaWU%3D)
Click to enlarge
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. | |
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, click Generate to automatically fill out the standard endpoints. You override with custom values at any point.
.png?sv=2022-11-02&spr=https&st=2025-05-05T14%3A52%3A28Z&se=2025-05-05T15%3A12%3A28Z&sr=c&sp=r&sig=4cb2Q8ysPabCMd76vL8DKnI8JpveeHgNT%2BbBAftyaWU%3D)
Click to enlarge
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. |
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
|
Redis Cache Optional. | Specifies an external Redis cache to be used for token/session storage. If unset, the default in-memory cache is used. |
Configure an OIDC application
From the Applications page, create an OIDC app by selecting OIDC-based under Application Types.

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. |
Grant Types | Select one or more grant types.
| |
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 Orchestrator clients should expect a 400 response with the error
| |
Client ID | The client ID OIDC clients will need to connect. |
|
Client Secret | The client secret OIDC clients will need to connect. |
|
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 Token Settings: Allow Lifetime Access | Defines whether a client can request refresh tokens. | |
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.
.png?sv=2022-11-02&spr=https&st=2025-05-05T14%3A52%3A28Z&se=2025-05-05T15%3A12%3A28Z&sr=c&sp=r&sig=4cb2Q8ysPabCMd76vL8DKnI8JpveeHgNT%2BbBAftyaWU%3D)
Click to enlarge
Field | Description |
---|---|
Name | Name of the user flow |
Application | The applications associated with the user flow.
|
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.
|
Authorization | Define access control rules for the applications Options
|
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
.png?sv=2022-11-02&spr=https&st=2025-05-05T14%3A52%3A28Z&se=2025-05-05T15%3A12%3A28Z&sr=c&sp=r&sig=4cb2Q8ysPabCMd76vL8DKnI8JpveeHgNT%2BbBAftyaWU%3D)
Click to enlarge
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 (e.g.,AWS S3,Google Cloud Storage,Github repore, 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.