Migrate from Self-Hosted OIDC

Migrate from Self-Hosted OIDC to Lurus Auth

The enterprise already runs an IdP (Keycloak / Auth0 / Okta / Azure AD) and wants employees to keep signing in with their corporate accounts while outsourcing the identity layer to Lurus.

Two Strategies

Strategy A: Lurus Auth as a Secondary IdP (Recommended)

You manage only the user lifecycle in your corporate IdP; Lurus products read identities through OIDC federation.

Strategy B: Full Relocation

Export your existing Keycloak/Auth0 to Lurus Auth (Casdoor) via SCIM and make it the single source of truth.

Strategy A — Federation Topology

Strategy A: Federation

graph LR
  IDP[Existing Enterprise IdP] -->|OIDC Federation| LA[Lurus Auth]
  LA --> P[All Lurus Products]

Strategy B — Relocation Topology

Strategy B: Relocation

graph LR
  KC[Original Keycloak/Auth0] -->|SCIM Export| LA[Lurus Auth · Casdoor]
  LA --> D[All Downstream]

Strategy A Steps (Recommended)

1. Create a federation connection in the Lurus console — Go to identity.lurus.cn → Enterprise Settings → Identity Providers → New → choose OIDC. Enter your corporate IdP's:

   • Issuer URL
   • Client ID
   • Client Secret
   • Callback URL (provided by Lurus)

2. Claim mapping — Map your corporate IdP's attributes to Lurus users.

   # 将企业 IdP 的属性映射到 Lurus 用户
   email:       email
   display:     name
   department:  department   # custom claim

3. Phased rollout — In your corporate IdP, first allow 5% of employees to use the Lurus sign-in button. Verify for 1 week → roll out to everyone.

Strategy B Steps

1. Export SCIM — Export users from Keycloak as JSON:

   ./kcadm.sh get users -r myrealm --fields username,email,firstName,lastName -f json > users.json

2. Batch import into Lurus

   POST/admin/v1/scim/users:batchImportBatch import users (identity.lurus.cn)

   curl -X POST https://identity.lurus.cn/admin/v1/scim/users:batchImport \
     -H "Authorization: Bearer $ADMIN_TOKEN" \
     -H "Content-Type: application/json" \
     -d @users.json

3. Password policy — By default Lurus does not migrate passwords (incompatible hashes); the first login forces a "forgot password" flow. If you use SSO federation, no password migration is needed.

Benefits of SSO Federation

Enterprise Compliance

The account lifecycle stays entirely within the enterprise.

Instant Offboarding

Deactivate in the corporate IdP → Lurus access is revoked immediately.

Unified Auditing

Sign-in logs live in the corporate IdP.

MFA Reuse

Your existing MFA policies remain in effect.

FAQ

Will sessions conflict?

Lurus uses its own session cookie and does not affect your original system.

Can PAT / JWT be kept?

Yes — API-level tokens are unaffected by the SSO migration.

How do I export audit logs?

All identity events can be batch-exported through the endpoint below:

POST/admin/v1/audit:exportBatch export identity events

Next Steps

Next steps

Lurus Auth OverviewOIDC / OAuth2Enterprise Deployment Topologies