Generic OIDC

For identity providers not covered by the named integrations (Auth0, Okta, Entra ID, Google, AWS IAM IDC), Mandaitor supports any standards-compliant OpenID Connect provider through the Generic OIDC integration.

Supported Providers

This integration works with any OIDC provider that:

• Publishes a /.well-known/openid-configuration discovery document
• Provides a JWKS endpoint for token signature verification
• Issues standard JWT access or ID tokens with iss, sub, aud, exp claims

This includes: Keycloak, PingIdentity, ForgeRock, Authentik, Zitadel, FusionAuth, Descope, Dex, Hydra, and any custom OIDC server.

Configuration

curl -X PUT https://api.mandaitor.io/v1/tenants/{tenantId}/identity-providers \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "enabled_providers": ["API_KEY", "COGNITO", "GENERIC_OIDC"],
    "generic_oidc": {
      "name": "Keycloak",
      "issuer": "https://auth.company.com/realms/production",
      "audience": "mandaitor-client",
      "subject_prefix": "keycloak"
    }
  }'

Configuration Fields

Field	Required	Description
name	Yes	Display name for the provider (shown in logs and UI)
issuer	Yes	OIDC issuer URL — must serve /.well-known/openid-configuration
audience	Yes	Expected aud claim in tokens
subject_prefix	Yes	Prefix for canonical subject IDs (e.g., keycloak → oidc:keycloak:<sub>)

How Detection Works

The Generic OIDC provider is registered last in the provider priority chain. This means:

1. Named providers (Auth0, Okta, Entra ID, Google, AWS IDC) are checked first by their domain patterns
2. If none match, the Generic OIDC provider accepts any JWT with an iss claim
3. During resolution, it validates that the token's issuer matches the tenant's configured issuer

This ensures named providers always take precedence, and the Generic OIDC provider only handles tokens from explicitly configured issuers.

Token Validation

1. Provider detection: Any JWT not matched by named providers
2. Issuer match: Token's iss must exactly match the configured issuer
3. JWKS discovery: Fetches JWKS from the issuer's /.well-known/openid-configuration
4. Signature verification: Standard RS256/PS256 JWT signature verification
5. Claims validation: iss, aud, exp checked against configuration
6. Identity resolution: Mapped to oidc:<subject_prefix>:<sub>

Examples

Keycloak

{
  "name": "Keycloak",
  "issuer": "https://auth.company.com/realms/production",
  "audience": "mandaitor-client",
  "subject_prefix": "keycloak"
}

PingIdentity

{
  "name": "PingFederate",
  "issuer": "https://sso.company.com",
  "audience": "mandaitor",
  "subject_prefix": "ping"
}

Zitadel

{
  "name": "Zitadel",
  "issuer": "https://auth.zitadel.cloud",
  "audience": "mandaitor-app",
  "subject_prefix": "zitadel"
}

Claims Extraction

The Generic OIDC provider extracts standard OIDC claims:

Claim	Used For
sub	Canonical subject ID
email	Display name fallback
name	Display name
preferred_username	Display name fallback
groups or roles	Available in raw_claims for authorization decisions
amr	MFA verification (for require_mfa constraints)