Differences

This shows you the differences between two versions of the page.

--- developers:admin:sso [2026/09/29 12:37] – chad
+++ developers:admin:sso [2026/09/29 14:12] (current) – [Common Provider Values] chad
@@ Line 25: / Line 25: @@
 | Subject claim | The claim that uniquely identifies a user. Use ''sub'' for most providers; ''oid'' for Entra ID. |
-<bootnote important>
+<bootnote>
 The Issuer URL must match the ''iss'' claim in your tokens exactly, including any trailing slash.
 </bootnote>
-==== Common Provider Values ====
 | **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'' |
+| 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'' |
+| 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'' |
+| 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'' |
+| 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'' |
+| Ping Identity | ''%%https://{env}.pingone.com/{envId}/as%%'' | ''sub'' | ''%%https://{env}.pingone.com/{envId}/as/jwks%%'' |
 ===== 2. Link Each User to Their SSO Identity =====
@@ Line 46: / Line 43: @@
 | subject | The subject-claim value (''sub''/''oid'') for that user, as issued by your IdP. |
-<bootnote important>
-''subject'' is the stable, opaque identifier from your IdP (a GUID for Entra ID, a numeric string for Google) &mdash; not the user's email address, unless your IdP is configured to use email as the subject.
-</bootnote>
 Set the link when onboarding, when creating a user, or on an existing user.
@@ Line 114: / Line 108: @@
 </bootnote>
-==== Finding a User's Subject Value ====
+===== 3. Logging In with SSO =====
-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.
+Log the user in with the standard [[developers:apiv2:connecting|LoginRequest]], but instead of ''username''/''password'' set your IdP's OIDC ID token in the ''id_token'' field. ''app_name'' and ''app_license'' are still required.
-<bootnote>
+<code>
-For Entra ID use ''oid'', not ''sub'': ''oid'' is stable across applications, whereas ''sub'' is scoped to a single client.
+// ClientMessage
-</bootnote>
+login_request {
+  id_token: "eyJhbGciOiJSUzI1NiIsImtpZCI6..."   // OIDC ID token from your IdP
+  app_name: "YourApp"
+  app_license: "YOUR-APP-LICENSE-GUID"
+  price_format: PRICE_FORMAT_DECIMAL
+}
+</code>
-===== 3. Logging In with SSO =====
+T4 validates the token (signature, issuer, and expiry) and signs in the user whose ''(issuer, subject)'' link matches. The reply is the usual ''LoginResponse''.
-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.
 ===== Checklist =====