SAML v2 IdP Initiated With Okta
This feature is only available in paid editions of FusionAuth. Please visit our pricing page to learn more about paid editions.
Configure SAML v2 IdP Initiated SSO With Okta
This page will guide you in configuring a SAMLv2 IdP Initiated Identity Provider with Okta as the initiating IdP. You will be able to visit an Okta provided link, authenticate and then be logged in to FusionAuth.
This document assumes you have an admin account with Okta and a valid FusionAuth paid edition license.
Create and Partially Configure the Okta SSO Application
Navigate to the Okta admin screen, and add an application. Search for SAML Service Provider
and add this type of application.

Add an Application label describing the application. Configure any other "General Settings" as needed.

Click "Next". You will arrive at the "Sign-On Options" section.

Click "View Setup Instructions". This will open needed instructions in a separate browser tab:

Record the Identity Provider Issuer and Identity Provider HTTP Post URL values. The former is a string such as exkq14ymac31Bx7895d6
. There may be a typo in the instructions with the string is
prefixed to the Identity Provider Issuer.
Download the "Identity Provider Certificate" too, then close the instructions tab.
Add the Okta Public Certificate to FusionAuth
Log in to the FusionAuth administrative user interface and navigate to
.Import the Okta provided certificate you just downloaded.

Add the SAMLv2 IdP Initiated Identity Provider
Navigate to
. Add a SAMLv2 IdP Initiated Provider.-
Configure the Name with a descriptive value.
-
Set the Issuer value to the Identity Provider Issuer value from Okta.
-
Set the Verification key to the public certificate you just imported.
Enable this Identity Provider for any FusionAuth applications. For this example, Pied Piper
allows use of this Identity Provider.
Any users who authenticate with Okta will be registered for this application because of the Create registrations setting.
All other options may be left with default values. Save the configuration.

View the Identity Provider in FusionAuth
View the created Identity Provider and navigate to the SAML v2 Integration details section.
Record the values of the Callback URL (ACS) and Issuer fields. Those will be used later.

CORS Settings
Navigate to
.
Determine the hostname and scheme of the Okta Identity Provider HTTP POST URL. If the URL is https://example.okta.com/app/generic-saml/11111151wmJ3HKZYD5d6/saml2
, then the hostname and scheme are https://example.okta.com
.
Add this value to the CORS Allowed origins field. Ensure that the POST
method is checked in the Allowed methods field. Save the configuration

Configure the FusionAuth Application Redirect URL
Navigate to Authorized redirect URLs field to include https://local.fusionauth.io/?client_id=CLIENTID
where CLIENTID is the value from the Client id field.
This URL is where a user will end up after authentication and may be any value URL.
Ensure the Authorization Code grant is enabled.

Complete SSO Configuration in Okta
Return to the
tab in the Okta Admin screen.-
Set the value of the Assertion Consumer Service URL to the value of the Callback URL (ACS) from the FusionAuth Identity Provider recorded above.
-
Set the value of the Service Provider Entity Id to the value of the Issuer recorded above.
-
Set the Application username format to be
Email
.

Save the Okta application by clicking "Done".
Scroll to the Embed Link value. This is the link a user needs to visit to begin the IdP initiated SSO, so you could place it in your application’s navigation, launchpad or elsewhere.
section and note theFinally, click on the
tab and assign the user to the application.
Test It Out
Open an incognito browser window and visit the Embed Link value. Log in with your Okta IdP credentials.

When you authenticate successfully, you will eventually land at the URL configured in the application’s Authorized redirect URLs field. The full URL contains an authorization code.
Since you configured registration for this Identity Provider, if the user did not previously exist in your FusionAuth instance, they will now have an account.
For a production application, the authorization code would be exchanged by your application for a JWT from FusionAuth.