Add Thoryn Hub as an OIDC IdP in your existing Okta tenant

What this enables

The customer already runs Okta as their corporate IdP. Migration off Okta is years away — but they want EUDIW / verifiable-credential support today. This recipe adds Thoryn Hub inside the Okta tenant as a third-party OIDC identity provider:

• Users land on the Okta login page (everything they're used to)
• They click Sign in with Thoryn (or an EUDIW-specific button)
• Okta redirects to Hub; Hub runs the credential flow (EUDIW presentation, verifiable-credential receipt, biometric step-up, etc.)
• Okta gets back a normalised OIDC profile and issues its own session

Okta is the user-facing IdP. Hub is the credential-protocol gateway behind it.

This is the inverse of okta, which has Hub federate to Okta. Pick the direction by who owns the user list — if it's Okta, use this recipe.

When to use

• Customer can't migrate off Okta but needs EUDIW / SD-JWT VC support
• Phased migration: ride along inside Okta first, decommission Okta later
• Multi-tenant SaaS where some customers want Thoryn-flavoured login on top of Okta

Prereqs

• Okta tenant URL (e.g. https://YOUR-COMPANY.okta.com)
• Okta Super Admin (Identity Providers UI is admin-only)
• A Thoryn account + Hub admin access

Step 1 — Register Okta as an OAuth2 client in Hub

hub clients create \
  --name "Okta tenant — YOUR-COMPANY" \
  --redirect-uri "https://YOUR-COMPANY.okta.com/oauth2/v1/authorize/callback" \
  --grant-types authorization_code,refresh_token \
  --scopes "openid email profile" \
  --client-type confidential

Capture client_id and client_secret — Okta will paste them in step 2.

Step 2 — Add Hub as an Identity Provider in Okta

Okta admin → Security → Identity Providers → Add Identity Provider → OpenID Connect IdP. Configure:

Step 3 — Map Hub claims to Okta user profile

Identity Providers → Thoryn Hub → Profile. Map:

For EUDIW-specific deployments, define a custom Okta user-profile attribute (e.g. eudiwLoa) and map it from a Hub claim emitted by your wallet-profile flow.

Step 4 — Configure routing rules

Identity Providers → Routing Rules → Add Rule. Decide which users see "Sign in with Thoryn":

IF: User's domain is "thoryn-customer.example"
THEN: Use Thoryn Hub

Or expose it as an option on the Okta login page:

IF: User clicks "Sign in with Thoryn"
THEN: Use Thoryn Hub

Step 5 — Test

In an incognito window, visit the protected Okta-protected app. The Okta login page should show Sign in with Thoryn as an option. Clicking it redirects to Hub, where the user authenticates (or presents an EUDIW credential, or steps up via biometric). Hub redirects back; Okta JIT-creates the user (or matches by email) and issues its own session.

EUDIW + verifiable-credential add-on

If you're using this recipe for EUDIW/SD-JWT VC presentations:

• In Hub, configure a wallet-profile that gates the OIDC flow on a successful Broker presentation (e.g. KYC-PID — see wallet-profiles/kyc-pid)
• Map Broker's verified claims (age_over_18, nationality, kyc_level, etc.) into Hub's ID-token custom claims
• Map those into Okta user attributes via step 3
• Use Okta's group-rule engine to gate downstream apps on eudiwVerified == true

Now an Okta-managed application can require an EUDIW credential at login, with Okta still handling SSO into the application, RBAC, and lifecycle.

Troubleshooting

• invalid_redirect_uri: Okta auto-generates the callback URL (https://YOUR-COMPANY.okta.com/oauth2/v1/authorize/callback). It must match the redirect URI in Hub exactly — copy it from Okta's IdP screen, paste into Hub admin.
• Could not match user: JIT-create has to be enabled on the IdP, OR the email must already exist as an Okta user. Check Profile Sourcing settings.
• Custom claims not flowing through: Hub emits custom claims based on the wallet-profile config. If a claim isn't appearing in Okta, verify it's actually present in the ID token (decode it at jwt.io); then check the Profile Mapping in Okta.

Pair with

• wallet-profiles/kyc-pid — gate the Hub-side flow on a Broker KYC presentation
• policy-engine/mfa-required-for-priv-actions — step up before Hub returns

See also

• okta — the inverse direction (Hub federates to Okta)
• hub-in-auth0 — same pattern, Auth0
• Hub — How it works
• Okta — OIDC IdPs docs