SSO Integration

This is an old revision of the document!

T4 supports single sign-on (SSO), letting your users log in with your own identity provider (IdP) over OpenID Connect (OIDC) instead of a T4 password. Your application obtains an OIDC token from your IdP and sends it in the T4 login request in place of the password.

Integrating SSO takes three steps:

Send your identity provider details to T4.
Link each T4 user to their identity in that provider.
Send the OIDC token at login instead of a password.

Protocol: OpenID Connect (OIDC).
Providers: Okta, Microsoft Entra ID (Azure AD), AD FS, Ping Identity, Google, Keycloak, or any standards-compliant Generic OIDC provider.

Email the following to [email protected]. T4 will confirm once the provider is set up.

Item	Description
Name	A short label for the provider, e.g. `Acme Corp Okta`.
Vendor	Okta, Entra ID, AD FS, Ping Identity, Google, Keycloak, or Generic OIDC.
Issuer URL	The `iss` value in your tokens, e.g. `https://acme.okta.com/oauth2/default`.
JWKS URI	The URL of your JSON Web Key Set. Listed under `jwks_uri` in `{issuer}/.well-known/openid-configuration`.
Subject claim	The claim that uniquely identifies a user. Use `sub` for most providers; `oid` for Entra ID.

Important: The Issuer URL must match the iss claim in your tokens exactly, including any trailing slash.

Provider	Issuer	Subject claim	JWKS URI
Entra ID	`https://login.microsoftonline.com/{tenantId}/v2.0`	`oid`	`https://login.microsoftonline.com/{tenantId}/discovery/v2.0/keys`
Okta	`https:{domain}/oauth2/default \| sub \| https:{domain}/oauth2/default/v1/keys`
Google	`https://accounts.google.com`	`sub`	`https://www.googleapis.com/oauth2/v3/certs`
AD FS	`https:{adfs-host}/adfs \| sub \| https:{adfs-host}/adfs/discovery/keys`
Ping Identity	`https:{env}.pingone.com/{envId}/as \| sub \| https:{env}.pingone.com/{envId}/as/jwks`

Link a user by adding an identityProvider object with two values:

Field	Description
issuer	The provider's issuer URL.
subject	The subject-claim value (`sub`/`oid`) for that user, as issued by your IdP.

Important: subject is the stable, opaque identifier from your IdP (a GUID for Entra ID, a numeric string for Google) — not the user's email address, unless your IdP is configured to use email as the subject.

Set the link when onboarding, when creating a user, or on an existing user.

Add identityProvider to the User object in the onboard request:

POST https://api.t4login.com/admin/v1/users/onboard

{
  "User": {
    "templateUser": "DefaultTemplate",
    "username": "[email protected]",
    "password": "SecurePassword123!",
    "firstname": "Alice",
    "lastname": "Smith",
    "email": "[email protected]",
    "apptype": "NonProfessional",
    "identityProvider": {
      "issuer": "https://acme.okta.com/oauth2/default",
      "subject": "00u1ab2cd3EF4GH5IJ6K"
    }
  },
  "Account": { "...": "..." },
  "MarketData": { "...": "..." },
  "Eula": { "...": "..." }
}

POST https://api.t4login.com/admin/v1/users

{
  "username": "[email protected]",
  "firstname": "Alice",
  "lastname": "Smith",
  "email": "[email protected]",
  "apptype": "NonProfessional",
  "identityProvider": {
    "issuer": "https://acme.okta.com/oauth2/default",
    "subject": "00u1ab2cd3EF4GH5IJ6K"
  }
}

PATCH https://api.t4login.com/admin/v1/users/{userID}

{
  "identityProvider": {
    "issuer": "https://acme.okta.com/oauth2/default",
    "subject": "00u1ab2cd3EF4GH5IJ6K"
  }
}

Note: To remove a link, PATCH with an empty issuer. Omit identityProvider to leave it unchanged.

Most IdPs let an admin list subject values in bulk (Object ID in Entra ID, user ID in Okta, numeric account ID in Google). For a single user, have them sign in and decode the token at https://jwt.ms (Entra ID) or https://jwt.io (other providers); the sub/oid claim is the subject value.

Note: For Entra ID use oid, not sub: oid is stable across applications, whereas sub is scoped to a single client.

Once your provider is set up and a user is linked, log the user in by sending the OIDC ID token from your IdP in the T4 login request, in place of the password. T4 validates the token and signs in the matched user.

Provider details sent to [email protected].
Every SSO user linked with the correct subject value.
At least one successful test login before go-live.

SSO Integration

What We Support

1. Send Us Your Provider Details

Common Provider Values

2. Link Each User to Their SSO Identity

During Onboarding

When Creating a User

On an Existing User

Finding a User's Subject Value

3. Logging In with SSO

Checklist

Documentation