Okta SAML and OpenID Connect With SSOGEN

Okta SAML works with SSOGEN as a standard SAML 2.0 provider, and Okta can also connect over OpenID Connect. Okta keeps the password and the second step.

Start a guided trial

Okta SAML with SSOGEN keeps Okta as the place users sign in and extends that sign-in to every application SSOGEN protects, including Oracle E-Business Suite, PeopleSoft and JD Edwards.

Okta. Checks the password and any second factor.
SSOGEN. Accepts the signed response and opens a session.
Protocol. Connect Okta as a SAML provider or as an OpenID Connect provider.
Users. Sign in as they do for any other Okta application and land in My Apps.

This page covers the Okta side of the choice. The screens and fields of the SSOGEN wizard are in the SAML guide and the OpenID Connect guide.

Choose SAML or OIDC for Okta

	SAML	OpenID Connect
In Okta	A SAML 2.0 application	A web application using the authorization code flow
You copy from SSOGEN	SP entity ID, ACS URL	Redirect URI
You copy from Okta	Metadata URL or XML file	Client ID, client secret, issuer
Expiry to watch	The signing certificate	The client secret

Either works. OpenID Connect is simpler; SAML is the better choice if your Okta administrators already use templates for SAML applications.

What to set in Okta for SAML

Start the Add SAML Provider wizard in SSOGEN and copy the three values it shows. In Okta, create a SAML 2.0 application and enter them:

Use the SP entity ID as the audience or identifier, and the ACS URL as the single sign-on and recipient address. The ACS uses the HTTP-POST binding.
Make sure Okta signs the assertion. SSOGEN refuses an assertion that is not signed.
Choose a NameID that is stable and unique for each person, such as the email address or the user principal name. SSOGEN builds the username from it, and a changed NameID creates a second account.
Add an attribute statement for the email address and, if you want it, the display name.
Assign the people or groups who may use the application.
Copy the application’s metadata address and give it to SSOGEN as the Metadata URL, or download the file and upload it.

What to set in Okta for OIDC

Create a web application that uses the authorization code flow, a confidential client.
Set the sign-in redirect URI to the value shown on the Client credentials step, exactly. SSOGEN’s test reports “The provider rejected the redirect URI” when they differ by even one character.
Allow the scopes openid, profile and email. Add groups only if you need group membership and Okta offers it.
Note the client ID and client secret. In SSOGEN, store the client ID under Settings > Secrets and enter its secret://stored/ reference, and type the secret into Client secret.
Find the issuer by opening <issuer>/.well-known/openid-configuration in a browser. Give SSOGEN the issuer value exactly as that document shows it, with no change to a trailing slash or path.

Find the attribute names Okta really sends

SSOGEN’s default SAML mapping uses the long Microsoft claim URIs, which suit Entra ID and AD FS. Okta lets the administrator name each attribute, and SSOGEN shows you exactly what it sends:

Create the provider with the defaults and run Validate and Test.
Select Try signing in and sign in as a real person. The result page lists What the provider sent, the NameID and every attribute name.
Copy those names into the Mapping step and save a revision.

If a field is left empty, SSOGEN recognizes common names such as mail and email. If the provider sends none of them, the account gets no email address rather than a wrong one.

Errors you are likely to meet

Message	Fix
The assertion was addressed to a different service provider	Set Okta’s audience to SSOGEN’s SP entity ID exactly
The response came back to a different ACS URL	Set Okta’s recipient and ACS to SSOGEN’s ACS URL
The assertion’s signature did not verify	Fetch the metadata again after Okta changes its certificate
The provider reports a different issuer	Copy the issuer from the discovery document
The provider refused the client id or secret	Check the stored client ID and that the secret has not expired
The provider did not ask anyone to sign in again	Sign out of Okta or use a private window and retry

Three settings complete the connection:

Second factor. The second step is set in Okta. SSOGEN records how strong the sign-in was, and the application’s own sign-in policy in SSOGEN can ask for more.
Sign-out. Turn on Also sign out of this provider so that signing out of SSOGEN ends the Okta session. Without it, the next page signs the person straight back in through Okta.
Sign-in domains. Add your email domains on the provider so people who type their address are sent to Okta.

Questions people ask

Does Okta use OAuth or SAML?

Okta supports both. SSOGEN connects to Okta over SAML and over OpenID Connect, which is built on OAuth 2.0.

What if my Okta client secret expires?

Create a new secret in Okta first. In SSOGEN, choose Replace client secret, save a revision, then Validate, Test and Activate it. People keep signing in on the old secret until you activate the revision.

Where to go next

SSOGEN works with Okta and with any other SAML 2.0 or OpenID Connect provider. Compare other providers on the hub, use the any SAML provider checklist, or read the identity providers guide. A row-by-row comparison is in Okta vs SSOGEN.