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
urn:ietf:params:oauth:grant-type:token-exchange - Token exchange
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 premises 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.

Configure Identity Services

Go to Identity Fabric
On the right, scroll and select an IdP
Enter all the required fields based on the service you select.
Learn More: Identity Fabric

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

OIDC Provider Configuration Reference

Core Endpoints

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.

Example: https://localhost:443

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.

Example: https://localhost:443/.well-known/openid-configuration

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.

Example: https://localhost:443/oauth2/auth

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.

Example: https://localhost:443/oauth2/token

Introspect

Used to validate and retrieve metadata about access tokens.

This corresponds to OAuth 2.0 Token Introspection, RFC 7662.

Example: https://localhost:443/introspect

Revocation

Used to revoke specific refresh or access tokens.

This corresponds to RFC 7009, section 2.

Example: https://localhost:443/revoke

End Session

RP-initiated logout endpoint. Allows clients to end the user session.

This corresponds to the OpenID Connect RP-Initiated Logout RFC.

Example: https://localhost:443/oidc/logout

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.

Example: https://localhost:443/userinfo

User Info Claims Extension (Optional)

Allows a Service Extension to customize claims in the user info response. Uses session attributes provided in the policy.

Security & Keys

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).

Example: https://localhost:443/.well-known/jwks.json

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 <>.

Optional Configuration

Redis Cache (Optional)

Specifies an external Redis cache to be used for token/session storage. If unset, the default in-memory cache is used. Learn More: Caches

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

Go to Applications, click Create, select OIDC-based.

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 urn:ietf:params:oauth:grant-type:token-exchange 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.
Custom OAuth Scopes	Maverics supports standard OIDC scopes such as openid, profile, email, and offline_access. Define any additional custom scopes your application needs to include in issued tokens. Custom scopes give you fine-grained control over which resources a client can access and what actions it can perform. By designing custom scopes that map to your domain (e.g., orders.read, vault.admin), you create clearer, safer, and more maintainable authorization rules.

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.

Configuring Token Minting Policies

From main navigation, click User Flows, and click on your OIDC App. Under Access Control → Access Token Minting OPA Policies, click on the Add button.

Access token minting policies control whether OAuth 2.0 access tokens can be issued during authentication flows. These policies provide fine-grained authorization control over token issuance based on user attributes, grant types, and custom business rules.

How It Works

When a client requests an access token, the system evaluates the token claims against configured authorization policies before issuing the token. If any policy approves the request, the token is issued. If all policies deny the request, token issuance is blocked.

Policies are written in Rego, the native policy language for Open Policy Agent (OPA). Rego enables you to express complex authorization logic using a declarative syntax that's both powerful and easy to audit.

Policy Evaluation

Multiple Policies: Configure multiple Rego policies that are evaluated in sequence
First Match Wins: Token issuance proceeds if any policy approves the request
Secure by Default: If all policies deny or no policies are configured as enabled, token issuance is blocked
Claims-Based: Policies evaluate against the full set of user claims and attributes
Grant Type Aware: Policies can differentiate behavior based on OAuth grant type (e.g., authorization code, refresh token, client credentials)

Common Use Cases

User Attribute Restrictions

Restrict token issuance to users with specific roles or group memberships
Block tokens for suspended or inactive accounts
Enforce organizational unit or department boundaries

Grant Type Controls

Disable refresh token grants for specific applications
Require stronger authentication for certain grant types
Implement conditional access based on authentication method

Time-Based Restrictions

Enforce business hours access policies
Implement token issuance windows
Apply temporary access restrictions

Custom Business Logic

Integrate with external authorization systems using Rego's built-in functions
Enforce compliance requirements
Implement risk-based authentication decisions (IP/ network, device/browser, behavior & timing, authentication strength)

Writing Policies with Rego

Policies receive context including:

Token Claims: All claims from the access token being evaluated
Grant Type: The OAuth 2.0 grant type being used
Request Context: Additional information about the authentication request
Refer to OPA Authorization for more details

Your Rego policies evaluate this context and return an authorization decision (allow or deny) along with optional messages explaining the decision.

Security:

When token issuance is denied:

The access token is immediately revoked to prevent reuse
An unauthorized error is returned to the client
The denial reason is logged for audit purposes

This ensures that tokens cannot bypass authorization policies even if they were previously issued.

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.