Blog · Guides

Okta SSO: what the admin configures, and what your app has to support

Okta single sign-on explained: Okta as the identity provider, SAML 2.0 and OIDC app integrations, the metadata your application needs, user assignment, and the failures that break sign-in.

Casdoor Team · November 7, 2026 · 4 min read

This guide is written by the team that builds Casdoor and describes the standards as published (listed under Sources), with notes on how Casdoor implements them as of November 7, 2026. Spotted a mistake? Tell us.

Okta SSO is single sign-on with Okta as the identity provider: users sign in once at Okta, and every application assigned to them opens without another password. Each application is an app integration in the Okta org, connected over SAML 2.0 or OpenID Connect.

Okta is one of the two identity providers enterprise buyers name most often (the other is Microsoft Entra ID). If you sell to enterprises, your product will eventually need to be a service provider to an Okta tenant.

The Okta model

Object What it is
Org The Okta tenant: users, groups, apps, policies
User and group The account and the groups it belongs to
App integration One application's connection to Okta
Assignment Which users or groups may use the app
Sign On tab The app's connection settings, certificate and metadata

SSO only works after assignment. A user who is not assigned to the app sees no tile and cannot sign in, even though the integration itself is correct.

Creating a SAML app integration

In the Okta Admin Console: Applications and Resources → Applications → Create App Integration → Classic experience → SAML 2.0.

The wizard has two parts:

  1. General settings: app name and logo.
  2. SAML settings:
    • Single sign-on URL: the application's assertion consumer service (ACS) URL.
    • Audience URI (SP Entity ID): the identifier the application expects in the assertion.
    • Default RelayState: optional landing path after login.
    • Name ID format: the user identifier format the app expects, for example emailAddress or persistent.
    • Application username: which Okta attribute is sent as the identifier.
    • Attribute Statements: extra claims such as email, first name, last name.
    • Group Attribute Statements: group membership, when the app authorizes by group.

After finishing, the Sign On tab shows the app's SAML settings, signing certificate and the Identity Provider metadata link. Give that metadata, or the certificate plus the SSO URL, to the application.

Okta signs assertions by default. If the app expects the response signed instead, or requires encrypted assertions, configure that on the Sign On tab; a mismatch appears as a signature error even though the certificate is right.

Creating an OIDC app integration

For a modern app, create an app integration with OpenID Connect as the sign-in method:

  • Choose the application type: web, single-page or native.
  • Add the redirect URIs the app uses after login.
  • Copy the client ID and, for confidential clients, the client secret.
  • Read the endpoints from the org's authorization server metadata, for example /oauth2/default/.well-known/openid-configuration.
  • Request the scopes the app needs: openid, profile, email, offline_access for refresh tokens.

OIDC integrations often still use the same assignment model, but they do not use the SAML Sign On tab.

What your application has to implement

Okta does half the work; the app does the other half:

  • An ACS endpoint that accepts an HTTP POST for SAML, or a redirect URI for OIDC.
  • Signature validation against Okta's certificate or JWKS.
  • Audience validation: the assertion must name your app's entity ID, and the ID token must name your client ID.
  • Time validation with a small clock skew allowance.
  • NameID or claim mapping to a local account.
  • A decision about IdP-initiated login: Okta portal tiles send unsolicited SAML responses. If you accept them, validate issuer, audience, recipient and replay cache strictly.

Common failures

  • ACS URL mismatch: the Single sign-on URL in Okta differs from the app's endpoint by scheme, path or trailing slash.
  • Audience mismatch: the app's entity ID and Okta's Audience URI are different strings.
  • Signature error: wrong or expired certificate, or the app expects a different signing target.
  • NameID rejected: the app requires emailAddress but Okta sends persistent, or the user has no email.
  • Missing attributes: the app reads a claim the wizard did not define.
  • User cannot sign in: the app is not assigned to the user or their group.
  • IdP-initiated response rejected: the app requires InResponseTo and the login started from the Okta tile.

Okta SSO and Casdoor

Okta is a commercial identity provider; its pricing is per user and per product line, as covered in Okta pricing. Casdoor is an open-source alternative that serves SAML 2.0, OIDC, CAS, LDAP and RADIUS from one deployment, with a hosted option that does not charge per user. For the feature and price comparison, see Casdoor vs Okta and Okta alternatives.

If you are migrating, Okta exposes users through its API, but passwords are not exportable; plan a password reset or a gradual cutover. The Okta migration guide covers what the Casdoor syncer can and cannot read.

FAQ

What is Okta SSO? Okta SSO is single sign-on where Okta acts as the identity provider: users sign in at Okta once, and assigned applications accept a SAML assertion or OIDC token from Okta instead of asking for a password.

Does Okta support SAML and OIDC? Yes. Okta has SAML 2.0 and OpenID Connect app integrations, plus proprietary and header-based options for older applications.

Why is my Okta SAML app failing with an invalid signature? The application usually has an old or wrong Okta certificate, or it expects the assertion signed while Okta signed the response. Check the Sign On tab's active certificate and the app's signing setting.

Do users need to be assigned to the Okta app? Yes. SSO works only for users or groups assigned to the app integration. Check assignments first when one user cannot sign in but others can.

Can I use Okta as an identity provider for my own product? Yes. Create an app integration for each customer tenant, or use a broker such as Casdoor to accept each customer's Okta tenant and give your app a single OIDC connection. See multi-tenant authentication.

Related reading: SAML SSO, SAML vs OIDC and SP-initiated vs IdP-initiated SSO.

Casdoor is open source and self-hostable, with a hosted option from $9 per month and no per-user fees.

Sources

Product names are trademarks of their respective owners.