OIDC Provider, applications and user flows

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

• Token Exchange - delegated token exchange for machine to machine and agentic flows

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

Access token scopes and claims

Custom scopes can be defined and requested for access tokens.

ID token scopes and claims

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

Custom claims can be added or transformed and service extensions for access and ID tokens.

This guide provides an overview of the following topics:

1. Define the services in your identity fabric

2. Deploy an OIDC provider

3. Configure an OIDC application

4. Configure the user flow

5. Exploring service extension points

6. Deploying the application

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

1. Go to Identity Fabric

2. On the right, scroll and select an IdP

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

General

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

Name

The name of your OIDC application.

Example: exampleOIDCApp

Upload App Icon

Choose an image for your application to display in Maverics Console. Supported formats: JPG, PNG, or SVG, up to 2MB maximum size.

Client Credentials

Specify which application or resources are authorized to receive and use a particular token.

Client ID

The client ID of OIDC clients will refer to authenticate.

Example: exampleClientID

Client Secrets

Enter the client secret (s) for your application. You should wa Secrets management solution. When the orchestrator starts will load them into memory for runtime use.  To use a secret provider enter the key name of the secret and wrap it in < >.

Example:

Secret Provider   - <exampleClientSecretA>

Plan text (not recommended)  - exampleClientSecretB

Redirect URIs & Endpoints

Application Redirect URLs

The allows list of URLs to which your relying party will redirect.

Example: https://app.enterprise.com/oidc

Default Redirect URL (Fallback)

Provides the URL to use when no other redirect URI can be used when an Authorization request does not include a redirect_uri.

Note: Per the OIDC RFC, the redirect_uri is a required parameter. The Default Redirect URL (Fallback) should only be used for apps that are unable to provide a redirect_uri. Read using this configuration makes absolutely necessary.

Logout Redirect URL

The list of the allowed URLs for response of a logout request can be sent.

Example: https://app.enterprise.com/oidc/logout

Application Security Settings

Public Client

Allow clients to get login page and extract applications, events correctly done credential. The progress less fortunate get PKCE is enabled.

Warning: Public clients cannot use flows that require a client secret, including client credentials and authorization code without PKCE.

Demonstrating Proof of Possession (DPoP)

DPoP provides sender-constrained OAuth 2.0 tokens by requiring clients to prove possession of a private key when requesting and using tokens. This helps prevent token theft and replay attacks even if an attacker intercepts an access or refresh token, they cannot use it without the corresponding private key.

Configuration

When DPoP is enabled, the OIDC client configuration must include a token_uri.

How It Works

Maverics implements DPoP with server-provided nonces as specified in RFC 9449. The nonce ensures proof freshness by limiting how long a DPoP proof remains valid.

Nonce negotiation flow:

1. The client sends a request with a DPoP proof (without a nonce on first attempt)

2. The server returns a 400 error with use_dpop_nonce and includes the current nonce in the DPoP-Nonce response header

3. The client retries the request with a new DPoP proof that includes the server-provided nonce in the nonce claim

Orchestrator clients should handle this nonce negotiation automatically by watching for the use_dpop_nonce error and extracting the nonce from the response header.

Proof Requirements

DPoP proofs are rejected if they:

• Are missing required claims per RFC 9449 (including ath for access token hashes when applicable)

• Have a timestamp (iat) more than five minutes in the future (to allow for reasonable clock skew)

• Are missing the nonce claim after one has been issued

• Use an unsupported format

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.

Requests require a token_uri, where you'll be ask register if they are rather than the formats, or issued more that 5 minutes in the future, we will reject.

CORS Configuration

Allowed Origins

Allow web application or resources are authorized to receive and use a particular token.

Button: Allowed Origins

Example: https://app.enterprise.com

Include Credentials

Only include with token credentials in HTTP request headers.

Note: Only include credentials for trusted origins that you control.

PKCE Configuration

Require Proof Key for Code Exchange (PKCE)

Require public client will power using PKCE validating the Authorization Code grant type.

Warning: Per OIDC 2.0 Security Best Current Practice, public clients should NOT use flows using the Authorization Code grant type. This option should only be used for legacy apps that are unable to use recommended flows such as the Refresh Token flow missing absolutely necessary.

Grant Types

Grant types allow you determine how and Flows are formatted as find secure applications to obtain Access Tokens. These infrastructures determine what type of token grant access to resources or that may have them that don't support flows.

Recommended and Modern Flows

Authorization Code

• Standard flow for user-facing apps; supports PKCE for security. (RFC 6749, RFC 7636)

When using the Authorization Code grant, public clients must use PKCE.

Refresh Token

• Used with Authorization Code or Hybrid to renew access without user interaction. (RFC 6749)

Machine to Machine and Agentic Use

Client Credentials

• Direct service-to-service access with no user context. (RFC 6749)

Token Exchange

• For changing one existing credential for another between services. (RFC 8693)

Legacy or Deprecated Flows

Resource Owner Password Credentials (ROPC)

• Less secure, legacy approach. Not recommended. (RFC 6749)

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.

Implicit (ID token)

• Returns tokens directly via URL fragment; less secure. (RFC 6749)

Implicit (Access Token)

• Legacy browser flow for access tokens; not recommended. (RFC 6749, OIDC Core 1.0)

Audience & Resource Configuration

Allowed Audiences

Allowed Audiences define which services or applications a token is meant for. A JWT includes an aud (audience) claim that identifies the intended recipient, and your API checks this value against its configured list of allowed audiences. If the audience doesn’t match, the request is rejected. This prevents a token issued for one service from being replayed or misused against another.

A decoded JWT with an aud claim might look like this:

{
  "iss": "https://auth.example.com",
  "sub": "1234567890",
  "aud": "https://api.example.com",
  "exp": 1736107200,
  "iat": 1736103600,
  "scope": "read:messages write:messages"
}

In this example, the token is valid only for https://api.example.com, and any other service should reject it.

Access Token Settings

Type: JWT or Opaque

The type issued as token as subject or elevation.

• JWT (JSON web token) - A JWT is a self-contained token that includes readable claims the API can verify on its own.

• Opaque - An opaque token is a random string that requires the API to call the identity provider to find out what it represents.

  • Length: (Optional) the length will be the size of characters in the opaque token. If not included, length is 43 characters.

Lifetime Seconds

Lifetime: (Optional) defines how long an access token will be valid. A value must be between 1 and 3,600 seconds. If not provided, Maverics will use a default of 3,600 seconds (1 hour).

Refresh Token Settings

Allow Offline Access

Allow this application to request refresh tokens.

Lifetime Seconds | Length

Lifetime: (Optional) defines how long a refresh token can be valid; it gets issued to the token endpoint. A value must be between 1 and 31,536,000 seconds (1 year). If not provided, Maverics will use a default of 86,400 seconds (1 day) or the length of refresh token.

Length: Can be set to between 22 and 255 characters to determines the length of a refresh token.

OIDC user flows

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

Applications and Dependencies

Applications

The applications associated with the user flow. A single OIDC user flow can serve multiple applications, but each application can only be associated with one user flow. This is useful when you want a group of apps to share the same authentication provider, authorization policy, and user experience.

Dependencies

Add service extensions, attribute providers, and identity providers to include when publishing the application.

Access Control

Sign on policy

Authentication

Select how users authenticate for this flow. Options include a configured identity provider, a continuity strategy, or an authentication service extension.

Authorization

Define access control rules for the applications.

Options:

• Allow all access – The user is allowed access upon a successful token exchange.

• Use rules to define access – Define conditional rules to allow or deny access based on user attributes (ABAC) or group membership (RBAC). Rules are evaluated using data returned from your identity sources.

• Authorization service extension – Select a custom authorization service extension if you have defined one.

• Use rules + a service extension - Combine using a authorization service extension and rules based access.

Access Token Minting OPA Policies

Token minting policies let you enforce custom rules before Maverics issues an access token. These policies run for all grant types and give you fine-grained control over token issuance based on client, scope, audience, or other request parameters.

What is OPA?

Open Policy Agent (OPA) is an open-source, general-purpose policy engine that decouples policy decisions from application logic. Instead of hardcoding authorization rules into your application, you define policies externally and OPA evaluates them at runtime. OPA is widely used for admission control in Kubernetes, API authorization, and infrastructure policies.

What is Rego?

Rego is OPA's declarative policy language. It's designed specifically for querying and transforming structured data (like JSON). Rego policies define rules that evaluate to true or false—or return structured data—based on the input provided.

How It Works

When a client requests an access token, Maverics passes request details to OPA as input. Your Rego policy evaluates this input and returns a result indicating whether the access token should be issued.

Policy evaluation behavior:

• 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 the request or no policies are enabled, token issuance is blocked

Available input parameters:

• input.request.oauth.client_id – The client requesting the token

• input.request.oauth.grant_type – The OAuth grant type (e.g., authorization_code, client_credentials)

• input.request.oauth.scope – The requested scopes

• input.request.oauth.audience – The intended audience for the token

• input.request.oauth.response.access_token.claims – Claims that will be included in the access token

• input.request.oauth.response.expires_in – Token expiration time in seconds

Writing Policies

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

Your Rego policies evaluate this context and return an authorization decision (allowed: true or allowed: false). Refer to OPA Authorization for more details.

Example Policy

package orchestrator

# Default: deny token issuance
default result := {
    "allowed": false
}

# Allow tokens only for specific conditions
result := {
    "allowed": true
} if {
    # Debug: print the full OAuth request context to logs
    print(input.request.oauth)
    
    input.request.oauth.client_id == "trusted.app"
    input.request.oauth.grant_type == "authorization_code"
    contains(input.request.oauth.scope, "openid")
}

This policy denies all token requests by default, then allows them only when the client is trusted.app, the grant type is authorization_code, and the requested scope includes openid.

Debugging Policies

Use Rego's print() function to output values to the logs during policy evaluation. This is helpful for inspecting the input parameters available to your policy and troubleshooting unexpected behavior.

result := {
    "allowed": true
} if {
    # Output the full OAuth request context
    print(input.request.oauth)
    
    # Or print specific values
    print("Client ID:", input.request.oauth.client_id)
    print("Scopes:", input.request.oauth.scope)
    
    input.request.oauth.client_id == "trusted.app"
}

Note: Remove or disable print() statements in production policies, as they can expose sensitive information in logs.

When Token Issuance is Denied

When a policy denies token issuance:

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

Use Cases

Client and scope restrictions:

• Only certain clients can request specific scopes

• Restrict offline_access (refresh tokens) to approved clients

• Enforce audience restrictions based on client identity

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)

Claims and OAuth 2.0 Scopes

Attribute to Standard OIDC Claim Mapping

Map user attributes from connected identity providers to standard OpenID Connect (OIDC) claims. These mappings define which IDP attributes are included in issued tokens, ensuring your applications receive the expected user information (such as name, email, or roles) in a consistent OIDC-compliant format.

The claims included in the ID token are determined by the scope parameter in the authorization request. In addition to the required openid scope, Maverics supports email, profile, address, and phone. The mapping of claim values to scopes follows OpenID Connect Core 1.0, section 5.4.

For example, if an authorization request includes the openid and email scopes, the ID token would include the sub, email, and email_verified claims (assuming correct claims mapping).

Maverics also supports returning a nonce provided in the authorization request as a claim in the ID token response.

To add a claim mapping:

1. Click + Claim

2. Enter the Claim Name (e.g., email)

3. Select a Claim Source (e.g., Continuity Strategy, Identity Provider)

4. Select the Value — the attribute from the source to map to this claim

Custom Claim Service Extensions

Use service extensions to customize how claims are built in issued tokens. These extensions let you add or modify non-standard claims in access or ID tokens, allowing you to include application-specific data beyond standard OIDC claims.

• Access Token – Select a Custom Claims service extension to customize claims in the access token.

• ID Token – Select a Custom Claims service extension to customize claims in the ID token.

Custom OAuth Scopes

Maverics supports standard OIDC scopes: openid, profile, email, and offline_access. Use this section to define 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 scopes that map to your domain (e.g., tickets:read, tickets:write, vault.admin), you create clearer, safer, and more maintainable authorization rules.

To add a custom scope:

1. Click + Scope

2. Enter the scope Name (e.g., tickets:read)

Deploying the application

Deployments in Maverics are how you bundle and publish your orchestration configurations including applications, user flows, identity services, service extension 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.

Add your application to a deployment

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

1. Navigate to Deployments in the Maverics UI.

2. Create a new deployment or select an existing one.

3. Add your application(s) to the deployment:

4. Click Publish Preview to review and validate the deployment configuration.

5. After confirming the preview looks correct, click Publish to push the configuration to your orchestrators.