OIDC (alternative)

OIDC is an alternative to the recommended single-app SAML 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↗ 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.

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 work the same as with SAML.

© 2026 LocalCan™. All rights reserved.