Generic OIDC IdP as a Hub federation member

What this enables

Any OIDC-conformant IdP federates with Hub. Use this as the starting point if your customer's IdP isn't in the per-vendor recipes.

Prereqs

• IdP issuer URL (e.g. https://idp.customer.example)
• OIDC discovery URL (<issuer>/.well-known/openid-configuration)
• IdP-side admin access to register Hub as an OIDC client

Step 1 — In the IdP

Register an OIDC client:

Capture the Client ID and Client Secret.

Step 2 — In Thoryn

id: generic-oidc
name: "Customer OIDC IdP"
type: oidc
issuer: https://idp.customer.example
client_id: ${CLIENT_ID}
client_secret: ${CLIENT_SECRET}
discovery_url: https://idp.customer.example/.well-known/openid-configuration
scopes:
  - openid
  - email
  - profile
claim_mappings:
  sub: sub
  email: email
  given_name: given_name
  family_name: family_name
  groups: groups   # if the IdP exposes them

Step 3 — Test

Trigger a login. Hub follows the OIDC discovery doc, redirects to the IdP, exchanges the code, and lands the user in your app with the mapped claims.

Troubleshooting

• given_name / family_name missing: many IdPs return only name. Use the name claim and parse on your side, or set claim_mappings.given_name: name (less correct but works).
• Discovery doc unreachable: paste the OIDC config inline if the IdP doesn't expose .well-known/openid-configuration.

See also

• Hub — How it works
• generic-saml — if the IdP only speaks SAML