Skip to main content
Okta SSO with OpenID Connect lets users sign in to Sofie with their Okta account through a customer-managed Okta OIDC web application.
Sofie supports two Okta sign-in methods: OpenID Connect (this guide) and SAML 2.0. If your identity team asked for SAML — the common choice for enterprise Okta deployments — use SAML SSO with Okta instead. Configure one method or the other, not both.

​
Before you start

You need:
  • Okta administrator access with permission to create app integrations.
  • A Sofie administrator account with access to Organization Settings > General and a passkey enrolled. Saving SSO settings requires a passkey confirmation.
  • The Sofie domain your users sign in to.
  • A test user assigned to the Okta app.
  • Magic-link sign-in left available until Okta sign-in is tested.

​
Sign-in redirect URI

Add this redirect URI to the Okta application, replacing the domain with your Sofie domain:
Sofie shows the exact deployment value, with a copy button, in Organization Settings > General > Okta Authentication. Use the exact URI — Okta does not accept wildcards here.

​
Create the Okta application

1

Create a new app integration

In the Okta Admin Console, go to Applications > Applications and click Create App Integration. Choose OIDC - OpenID Connect, then Web Application.
2

Enable the Authorization Code grant

Under grant types, make sure Authorization Code is enabled.
3

Add the sign-in redirect URI

Add https://<your-sofie-domain>/api/auth/callback/okta as a sign-in redirect URI.
4

Assign users

Assign the users or groups allowed to access Sofie, including your test administrator account.
5

Copy the client credentials

From the application’s Client Credentials section, copy the Client ID and the Client secret.

​
Add values in Sofie

In Sofie, go to Organization Settings > General, find Okta Authentication, and turn on Enable Okta to show the configuration fields. Click Save Changes and complete the passkey confirmation.
For standard SSO, use the organization URL as the issuer. Use /oauth2/default or another custom authorization server only when the Okta administrator has configured its access policy for this application.
Do not paste client secrets into chat, CoDrafts, Workspaces, screenshots, or public docs. Use the secure organization settings fields only. If a secret is already saved, leave Client Secret blank unless you are rotating it.

​
Test Okta sign-in

Click Test Okta sign-in in the Okta Authentication section and complete the Okta sign-in with an assigned account. A successful test marks the provider verified, which is required before magic links can be disabled. Then open the Sofie sign-in page in a private window and confirm the Sign in with Okta button works for a regular test user. Sign-in requests the openid, profile, and email scopes.

​
User provisioning and account linking

  • A new user is created on first Okta sign-in. If the user has a pending Sofie invitation, its role and group assignments apply; otherwise the user gets the organization’s default role.
  • Sofie links Okta sign-ins to existing accounts by email address, so users who previously used magic links keep their history and access. Existing accounts must have a verified email address to be linked.
  • Okta groups do not map to Sofie roles. Assign roles through invitations, the default role, or user management.
Once Okta sign-in is verified, you can turn on Disable magic links when SSO is enabled in Authentication Policy. The setting stays locked until an external provider is verified, which prevents administrator lockout during setup. See Organization settings for the full policy behavior.

​
Troubleshooting

Confirm Enable Okta is on and the client ID, issuer URL, and client secret are all saved.
Confirm the application includes https://<your-sofie-domain>/api/auth/callback/okta exactly, with no wildcard port and the correct domain and protocol.
Use the plain organization URL such as https://customer.okta.com. If you used /oauth2/default or a custom authorization server, confirm its access policy allows this application.
Check whether the client secret was rotated in Okta, the application was deactivated, or the user’s assignment was removed.