Skip to main content
Version: 2026.10

Preparation checklist

Before registering the Identity Service with your provider, confirm the application addresses and settings below.

Application addresses​

AddressValue
Sign-in callbackhttps://api.<platform-host>/identity/callback
Sign-out returnhttps://<platform-host> and any additional approved frontend addresses

<platform-host> is the frontend hostname in common.mainFqdn, without https://. With common.mainFqdn: istari.example.com, the callback is https://api.istari.example.com/identity/callback.

If common.apiFqdnOverride is set, use that hostname instead of api.<platform-host>. For example, common.apiFqdnOverride: api.example.com gives https://api.example.com/identity/callback. An explicit ISTARI_DIGITAL_IDENTITY_SERVICE_BASE_URL takes precedence: the callback is that full URL, including any path prefix, plus /callback.

Register exact addresses without wildcards. The chart allows https://<common.mainFqdn> as the frontend return address; include any additional addresses in ISTARI_DIGITAL_IDENTITY_SERVICE_FRONTEND_REDIRECT_URIS. Google has no upstream sign-out return setting.

Application and credentials​

  1. Register a confidential OIDC web application with Authorization Code and S256 PKCE. Configure scopes and refresh access as specified by your provider's guide.
  2. Record the client ID and the issuer from the provider's OpenID configuration. Transfer the client secret or application key securely to the installation operator and store it in a Kubernetes Secret.
  3. Set the guide's identity.oidc values. These override matching Secret values; identity.env takes precedence over both. Remove conflicting settings when changing providers. Leave DISCOVERY_API_VERSION at its default, 2.

Continue with Set up with the provisioner. Before users sign in, prepare their tenants and accounts and grant administrator access.

For an existing Zitadel installation changing providers, follow Switching from Zitadel. That procedure supports outgoing Zitadel only.

Test the connection​

Sign in with a prepared test account in a private browser window. Check its tenant, roles, resource access, and provider-specific sign-out behavior. Sign in again and confirm the same account is used. Check that unprepared accounts are refused where required by the provider's enrollment policy.

After a migration, also check existing file ownership, editing, and sharing as both owner and recipient.