Okta Integration Wizard: SSO settings

Protocol-specific fields for configuring single sign-on with OIDC or SAML.

OIDC

Keep the following OIDC limitations in mind:

When you create your app integration in your Okta org, select Web Application as the OIDC app type.
Native and mobile app integrations aren't accepted as OIDC app integrations in the OIW unless they use server-side authentication patterns. Set up your app to use an authentication flow that allows your client app to talk to your SaaS backend. Your SaaS backend can then securely communicate with Okta through trusted back-channel connections. See Implement the authorization code flow.
The Implicit flow isn't recommended for token exchange in web apps. If your use case requires the use of an Implicit flow for token exchange, contact Okta Support.
You can't use a custom authorization server that includes the default server for an OIDC or API service integration. You can only use the org authorization server. The following are the various /authorize request URLs for the different authorization servers:
- Custom authorization server: https://{customerOktaDomain}/oauth2/{authorizationServerId}/v1/authorize?client_id={clientId}&response_type=code&scope=openid&redirect_uri={redirectURI}&state={state}
- default custom authorization server ({authorizationServerId}=default): https://{customerOktaDomain}/oauth2/default/v1/authorize?client_id={clientId}&response_type=code&scope=openid&redirect_uri={redirectURI}&state={state}
- org authorization server: https://{customerOktaDomain}/oauth2/v1/authorize?client_id={clientId}&response_type=code&scope=openid&redirect_uri={redirectURI}&state={state} Make sure that you only use the org authorization server URL. When you use the org authorization server, the issuer URL is https://{yourOktaDomain}.
You can't use the Okta SDKs to validate access tokens with the org authorization server. This is due to the OIW restriction of using an org authorization server and the authorization code flow.
Refresh tokens aren't supported for SSO OIDC integrations published in the OIW. Therefore, offline_access scopeisn't available because refresh tokens aren't supported for integrations published in the OIW.
Custom scopes, such as the groups scope, aren't supported.
Don't rely on the email_verified scope-dependent claim that an OIDC integration returns to evaluate whether a user has verified ownership of the email address that's associated with their profile.

Note: See OIDC-specifc Dynamic properties with Okta Expression Language for entering URIs.

Table 1. OIDC fields
Field	Description
Redirect URIs	Specify one or more redirect URIs for your app. If your URI varies per tenant, include the variable names that you created in your URI. For example: `https://{app.subdomain}.example.org/strawberry/login`. The maximum field length is 1024 characters. This is a required field. Click + Add another to add more URIs.
Initiate login URI	Specify the URI to redirect users when they select your app from their End-User Dashboard. This URI is optional and is used if your integration handles constructing an authorization request and redirecting the end user back to Okta. You can use integration variables if your initiate-login URI varies per tenant. For example: `https://{app.subdomain}.example.org/strawberry/start-login`.
Post-logout URI	Specify the sign-out redirect URIs for your app. Include a sign-out URI if you have a location where you want to send your end user after they sign out of your app. You can use integration variables if your sign-out URI varies per tenant. For example: `https://{app.subdomain}.example.org/strawberry/logout`. Click + Add another to add more URIs.

SAML

Keep the following SAML limitations in mind:

SAML integrations must use SHA256 encryption for security. If you're using SHA-1 for encryption, see our guide on how to Upgrade SAML Apps to SHA256.
You can only submit SAML 2.0 integrations.
There's a maximum of three app instance variables allowed.
RelayState can't be preconfigured in the OIW. You can set the default relay state value at the app instance level in the app's Sign On tab.
The force authentication (ForceAuthn) functionality is enabled by default for SAML app instances that were created from an OIW integration. You can disable force authentication for an app instance by selecting Disable Force Authentication in the app's Sign On tab.
SP-initiated Single Logout (SLO) isn’t supported.
The OIW doesn't accept new SSO integrations with more than three app instance variables or advanced SAML features. For these new integrations, add a custom SSO integration with the Classic experience (formerly called the Application Integration Wizard) in your Okta org instead.

Note: See the SAML-specifc Dynamic properties with Okta Expression Language for entering URLs.

Table 2. SAML fields
Field	Description
Default ACS URL	Specify the default Assertion Consumer Service (ACS) URL. If you're using a per-tenant design, include the variable names that you created in your URL. For example: `https://${org.subdomain}.example.org/strawberry/login`. All static URLs must begin with `https://` and be complete. For URL expressions, you can use any valid format. The maximum field length is 1024 characters. This is a required field.
Additional ACS URLs	Optional. Provide an indexed ACS URL if your integration supports multiple ACS URLs where Okta can send the SAML response. Adding an indexed ACS URL is optional, but if you add one, both properties are required: ACS URL: Specify another ACS URL. The maximum field length is 1024 characters. Index: Specify the index for the corresponding ACS URL. You can't reuse the same index in the list, and the index must be an integer 0–65535. Click + Add another to add more URLs.
Entity ID / audience restriction	Specify your SAML entity ID or the audience restriction. This is a required field.
Attribute statements	Optional. Specify the attribute name and values of your claim. Adding a claim is optional, but if you add one, both properties are required: Attribute name: Specify the claim name. Values: Specify a comma-separated list of values for the claim. Note: Ensure that you use valid user profile properties when referencing attribute values in EL expressions. The system rejects any invalid user EL expressions and attributes that aren't included in the allowlist. The acceptable value for Okta username is `${user.userName}`. The rest of the attributes from the Okta user profile should follow the format `user.<attributeVariable>` and the Application user profile attributes should follow the format `appuser.<attributeVariable>`. Click + Add another to add another claim.
Group attributes	Specify your group attribute statements if your app supports receiving SAML group attribute statements. See Define attribute statements and Define group attribute statements for details on configuring attribute statements. Click + Add another to add more statements.