# OIDC (alternative)

OIDC is an alternative to the recommended [single-app SAML setup](/docs/sso/okta-setup). It works with **any OpenID Connect provider** that publishes a discovery document and supports the authorization code flow: Okta, Google Workspace, Microsoft Entra ID, Auth0, OneLogin, Keycloak, and others.

You might prefer OIDC if your org standardizes on it, if your provider makes OIDC apps easier to create than SAML apps, or if you only need SSO sign-in without SCIM provisioning.

The trade-off for Okta users: Okta doesn't support SCIM on custom OIDC apps, so provisioning requires a second, provisioning-only app. With SAML, one app does both.

#### Connection setup

Create an OIDC web application in your provider, then select `OIDC` in the protocol dropdown on the LocalCan SSO page:

- **Issuer**: your provider's issuer URL, e.g. `https://your-org.okta.com` or `https://accounts.google.com`. LocalCan validates it against its `/.well-known/openid-configuration` at registration.
- **Client ID** / **Client secret**: from your provider's app. The secret is write-only; LocalCan never displays it again.
- The app's **redirect URI** (callback URL) must exactly match the value on your SSO settings page.
- The provider must assert the user's **work email** (the standard `email` claim).

Domain verification works the same as with SAML.

Okta-specific: set **Application username** to `Email`, and note that OIDC app tiles *can* initiate sign-in directly. On the app's **General** tab, set Login initiated by to **Either Okta or App**, Login flow to **Redirect to app to initiate login (OIDC Compliant)**, and paste the **Initiate login URI** from your SSO settings page.

#### Adding SCIM provisioning

SCIM provisioning is validated with **Okta** today; for other providers' SCIM clients, contact [support@localcan.com](mailto:support@localcan.com) first.

With Okta, provisioning runs through a separate app: create a **SWA** app (users never launch it; hide its icon), set its Provisioning to `SCIM`, and configure the Provisioning tab as in [step 4 of the SAML guide](/docs/sso/okta-setup).

Two rules keep the two Okta apps in lockstep:

1. **Assign the same Okta group to both apps.** If they drift, a user can sign in but never get provisioned, or be provisioned but unable to sign in.
2. **Application username is `Email` on both apps.**

Token rotation and the [user lifecycle](/docs/sso/user-lifecycle) work the same as with SAML.