Skip to main content
This guide applies to any identity provider that implements the OpenID Connect (OIDC) standard — including PingIdentity, ForgeRock, OneLogin, JumpCloud, CyberArk Identity, and others not covered by a dedicated Vikat guide.

​
Prerequisites

  • An OIDC-capable identity provider with admin access
  • Vikat Enterprise deployed and accessible
  • Your Vikat callback URL: https://<your-vikat-domain>/login
  • The ability to create a confidential (client secret) OAuth 2.0 application in your IdP
  • Vikat roles created for the roles you plan to map

​
Step 1: Create an OIDC application in your IdP

1

Register a new application

In your identity provider’s admin console, create a new application. Look for options like Create App Integration, Add Application, New Application, or Register Client.Choose a type that matches the Authorization Code flow with a server-side callback — typically Web Application or Regular Web Application with a Confidential client. Avoid SPA or Native types.
2

Configure redirect URIs

Set the following URIs in your IdP:Save the application.

​
Step 2: Configure token claims

1

Ensure the required scopes are requested

Your application must request the following OAuth scopes:
  • openid — required for OIDC
  • profile — provides name, given_name, family_name
  • email — provides the user’s email address
  • offline_access — provides a refresh token for session maintenance (if supported)
2

Include group or role claims

For role and team mapping to work, your IdP must include group memberships or role values in the ID token.Any claim present in the ID token is available for mapping in Vikat.

​
Step 3: Copy your credentials

1

Note the Issuer URL, Client ID, and Client Secret

From your application settings, copy:The issuer URL typically looks like https://auth.company.com or https://auth.company.com/realms/my-realm. Vikat uses it to discover endpoints via <issuer>/.well-known/openid-configuration.

​
Step 4: Assign users

1

Grant users access to the application

In your IdP, assign the users or groups that should be able to log in to Vikat:
  • Explicit assignment — add users directly to the application
  • Group-based access — assign a group; all members get access
  • Policy-based — configure an access policy
Only users explicitly granted access can authenticate via Vikat.

​
Step 5: Configure Vikat

1

Open User Provisioning and choose Generic OIDC

In your Vikat dashboard, go to Governance → User Provisioning.Select Generic OIDC Provider and click Next.
Vikat Choose Provider screen with Generic OIDC Provider selected

Select Generic OIDC Provider from the list of identity providers.

2

Fill in the provider configuration

Enter the credentials you copied in Step 3:Click Discover endpoints to auto-fill the authorize, token, and userinfo endpoints from your issuer’s discovery document. Then click Verify & Next.
Vikat Provider Configuration form showing Issuer URL, discovered endpoints, Client ID, Client Secret, and optional Audience fields

Provider Configuration — enter your OIDC issuer URL and client credentials, then Discover endpoints to validate.

3

Discover claims

On the Attribute Mapping screen, click Discover Claims to fetch live claims from your IdP.Vikat opens a sign-in popup — no session is created. Once you authenticate, it returns the exact claims your IdP is sending in the JWT. Use this to confirm which attributes — groups, roles, department, or custom claims — are present before building your mappings.
Vikat Discover Claims screen listing all claims returned by the generic OIDC provider

Discover Claims — shows all claims the IdP is returning in the JWT so you can reference exact names when building mappings.

If Discover Claims fails, confirm your IdP is configured to allow the openid, profile, and email scopes and that the discovery callback URI is registered.
4

Set up attribute mappings

Use the sections below the claim list to map IdP claim values to Vikat roles, teams, and business units.Attribute-to-Role MappingsMap a claim value to a Vikat role. All matching rules are evaluated — if multiple rules match, the role with the highest permissions is assigned. If no rule matches, login is denied.Attribute-to-Team MappingsMap a claim value to a Vikat team. All matching rules apply.
  • Use a specific value (e.g. engineering) to map that exact claim value to a named team
  • Use * to sync the claim value directly as the team name
  • Use ${*} to extract part of the string — e.g. /${*} matches /Engineering and creates team Engineering
Attribute-to-Business Unit MappingsSame wildcard support as team mappings. When a rule matches, the resolved business unit is assigned to all of that user’s teams.
Vikat Attribute Mapping screen showing role and team mapping rules configured for the generic OIDC provider

Attribute Mapping — configure role, team, and business unit rules based on the claims your IdP sends.

Setting a value to * maps the claim value directly as the entity name. Value comparisons are case-insensitive.
Click Next when done.
5

Review and enable

Review your full configuration — connection details, attribute mappings, and SCIM status — then click Save & Enable.
Vikat Review and Enable screen showing Generic OIDC Provider connection details and configured attribute mappings

Review & Enable — confirm your connection and mappings before activating the provider.

Restart your Vikat server after enabling for the changes to take effect.

​
How background sync works

Vikat refreshes active OIDC sessions every 15 minutes. If a session cannot be refreshed, Vikat checks with your IdP whether the user is still active; if the IdP reports the user as inactive, Vikat decommissions that user locally. For providers that support it, see SCIM with Generic OIDC to enable real-time user and group provisioning.

​
Troubleshooting

User is not redirected to the IdP — verify the provider is enabled in Vikat and the server was restarted after saving. Confirm the Issuer URL has no trailing slash and is reachable from your Vikat server. JWKS validation fails — Vikat fetches <issuer>/.well-known/openid-configuration to discover the JWKS endpoint. Ensure this URL is reachable from your Vikat host. Audience mismatch — set the Audience field in Vikat to match the aud claim in the JWT. Leave blank to default to the Client ID. Claims are present in Discover Claims but role mapping is not working — confirm the claim name matches exactly what the IdP sends (case-sensitive, including namespacing). Dotted paths (e.g. realm_access.roles) are supported. Login fails after successful IdP authentication — check that the redirect URI in your IdP exactly matches https://<your-vikat-domain>/login. Trailing slashes and path differences are not allowed.