SSO, the fields

Every field in a SAML Response, an OIDC authorization response and ID token, a back-channel logout token and a launch token, with what it is for and which check refuses it. A reference for reading a response against a handler.

This is a reference. The argument is in the decision post, and the handlers these rows point at are in the mechanics post. Each table is one message, shown once on the wire above the table, stripped to what the receiver checks. Each row is one field, with what it is in plain words, an example of its value, and the check that refuses it when it is wrong, named the way the handler names it. The examples use the same made-up names as the mechanics post's samples. Where a check rests on a sentence of a spec, the sentence is cited after the table.

The SAML Response

Arrives by the HTTP-POST binding as a base64 form field named SAMLResponse, with RelayState beside it. The handler is accept_unsolicited_response for the IdP-initiated case. The solicited case makes the same checks with the two InResponseTo lines inverted. Listing 1 is the solicited document, so it carries both InResponseTo attributes, and the unsolicited handler would refuse exactly those two, and accept the same document without them.

<samlp:Response ID="_r9" Version="2.0" IssueInstant="2026-09-27T16:00:00Z"
    Destination="https://partner.example.net/saml/acs"
    InResponseTo="_req5f3a">
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <ds:Signature>...</ds:Signature>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <saml:Assertion ID="_a1b2c3" ...>   the whole of Listing 3 goes here   </saml:Assertion>
</samlp:Response>

The form that carried it had two fields, SAMLResponse holding the base64 of the document above and RelayState=orders beside it. This is the solicited case, answering the request in Listing 13, so InResponseTo is present here and on the bearer confirmation in Listing

1. The unsolicited case is the same document without those two

attributes. When the Assertion is encrypted, the Assertion element is replaced by the one in Listing 2.

<samlp:Response ID="_r9" Version="2.0" IssueInstant="2026-09-27T16:00:00Z"
    Destination="https://partner.example.net/saml/acs" InResponseTo="_req5f3a">
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <ds:Signature>...</ds:Signature>
  <samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>
  <saml:EncryptedAssertion>
    <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element">
      <xenc:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#aes256-gcm"/>
      <ds:KeyInfo>
        <xenc:EncryptedKey>
          <xenc:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#rsa-oaep"/>
          <ds:KeyInfo><ds:KeyName>partner-enc-2026</ds:KeyName></ds:KeyInfo>
          <xenc:CipherData><xenc:CipherValue>base64 of the AES key, encrypted to the partner's public key</xenc:CipherValue></xenc:CipherData>
        </xenc:EncryptedKey>
      </ds:KeyInfo>
      <xenc:CipherData><xenc:CipherValue>base64 of the encrypted Assertion</xenc:CipherValue></xenc:CipherData>
    </xenc:EncryptedData>
  </saml:EncryptedAssertion>
</samlp:Response>

Every Response-level field, the two algorithm names, and which partner key the content key was wrapped with are in the clear, and therefore readable in a log or a HAR file. Nothing about the user, the audience, the Assertion's times or the attributes is visible until the outer signature holds and the Assertion is decrypted.

The SAML Assertion

The Assertion travels inside the Response, as a child element, in the clear as Assertion or encrypted as EncryptedAssertion. The Response is the envelope, with the status, the destination and its own signature, and the Assertion is the statement about the user. The profile requires at least one. The handler takes exactly one, verifies every signature present, and requires one whose reference encloses the element it reads the subject from.

<saml:Assertion ID="_a1b2c3" Version="2.0" IssueInstant="2026-09-27T16:00:00Z">
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <ds:Signature>...</ds:Signature>
  <saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
        NameQualifier="https://idp.example.com"
        SPNameQualifier="https://partner.example.net">p-8c21e0</saml:NameID>
    <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml:SubjectConfirmationData NotOnOrAfter="2026-09-27T16:05:00Z"
          Recipient="https://partner.example.net/saml/acs"
          InResponseTo="_req5f3a"/>
    </saml:SubjectConfirmation>
  </saml:Subject>
  <saml:Conditions NotBefore="2026-09-27T15:59:00Z" NotOnOrAfter="2026-09-27T16:05:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://partner.example.net</saml:Audience>
    </saml:AudienceRestriction>
    <saml:OneTimeUse/>
  </saml:Conditions>
  <saml:AuthnStatement AuthnInstant="2026-09-27T15:58:30Z" SessionIndex="s-77"
      SessionNotOnOrAfter="2026-09-28T00:00:00Z">
    <saml:AuthnContext>
      <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
    </saml:AuthnContext>
  </saml:AuthnStatement>
  <saml:AttributeStatement>
    <saml:Attribute Name="mail">
      <saml:AttributeValue>ada@customer-a.example</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

This Assertion carries its own signature as well as being covered by the Response's, which is the belt-and-braces shape some identity providers send. Either one alone satisfies the handler unless the partner's metadata says WantAssertionsSigned, in which case the Assertion's own is required. NotBefore on the bearer confirmation is the one field the table names that is absent on purpose.

The Response issuer rule and the bearer confirmation's end-and-no-start are Web Browser SSO Profile section 4.1.4.2. Every assertion delivered by POST must be covered by a signature, its own or the Response's, profile 4.1.4.5 as amended by erratum E26. Every audience restriction is evaluated on its own, Core 2.5.1.4. An unevaluable condition makes the assertion indeterminate, Core 2.5.1.1. The replay cache is keyed to the bearer window, profile 4.1.4.5. RelayState is limited to 80 bytes by the bindings specification. Identifier uniqueness is Core 1.3.4 and all time values being UTC is Core 1.3.3. Destination is optional, and when present the receiver must check it against the address the message arrived at, Core 3.2.2. The rule that a signed message must carry it is the HTTP-POST binding's, Bindings 3.5.5.2.

The OIDC authorization response

The redirect back to the callback, by GET or by form_post. The handler is handle_callback, and the third-party-initiated flow ends in the same one.

GET /sso/callback
  ?code=SplxlOBeZQQYbYS6...
  &state=Q4w9pLm2...
  &iss=https%3A%2F%2Fidp.customer-a.example
Host: app.partner.example
Cookie: __Host-pending=9c1f...

Why a GET. The identity provider finishes the login on its own site and has to get the browser back to the partner's callback, and the ordinary tool a server has for that is a redirect, an HTTP 302 with a Location header. The request being redirected is the browser's own GET of the authorization endpoint, and a browser follows a 302 to a GET, so the code and the state arrive in the query string. That is OAuth's default response_mode=query. The identity provider never talks to the callback itself. The browser does, carrying what the identity provider put in the URL. The cost is a URL's. The code is visible in browser history and access logs, which the protocol accepts because the code is single-use, short-lived, and useless without the PKCE code verifier. The alternative is response_mode=form_post, where the identity provider returns a small page whose form auto-submits a POST to the callback, the same shape as SAML's HTTP-POST binding, and the handler accepts both. A top-level GET carries the partner's Lax cookies and a cross-site POST does not, which is why the pending cookie is SameSite=None and why the SAML path needs the stash and bounce, the extra hop the mechanics post adds so a cross-site POST ends in a top-level GET that carries the cookie.

The error form of the same arrival replaces code with error=login_required and keeps state, so the handler can still find the request it answers.

POST /token HTTP/1.1
Host: idp.customer-a.example
Authorization: Basic cGFydG5lci1hcHA6czNjcjN0
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
  &code=SplxlOBeZQQYbYS6...
  &redirect_uri=https%3A%2F%2Fapp.partner.example%2Fsso%2Fcallback
  &client_id=partner-app
  &code_verifier=dBjftJeZ4CVP...

The body is one line on the wire, the five parameters joined by &. It is split here so each can be found.

{
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "token_type": "Bearer",
  "expires_in": 300,
  "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjIwMjYtMDkiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOi...dmVyaWZpZWQiOnRydWV9.signature"
}

The partner, not the browser, makes this request, server to server, authenticating as the client (here with HTTP Basic, but a private-key JWT is the stronger option). code_verifier is PKCE's code verifier, the secret the partner made at start_login and kept in the pending record (the mechanics post's code stores it as pkce_verifier, and the wire parameter name is code_verifier, from RFC 7636). The identity provider hashes it and compares the result with the code_challenge the request in Listing 12 carried, and refuses the exchange on a mismatch. redirect_uri must be the one the request carried. The id_token in the answer is Listing 7.

The iss rule is RFC 9207 section 2.4. One callback path per issuer is the alternative RFC 9700 section 4.4.2 allows, and the handler requires it for a tenant that does not send iss. The token endpoint's response is checked at step 4, where an ID token must be present and token_type must be Bearer, Core 3.1.3.3.

The ID token

Returned by the token endpoint in the code flow. Verified at step 5 with the tenant's keys, then read claim by claim at step 6.

header     eyJhbGciOiJSUzI1NiIsImtpZCI6IjIwMjYtMDkiLCJ0eXAiOiJKV1QifQ
           {"alg": "RS256", "kid": "2026-09", "typ": "JWT"}

payload    eyJpc3MiOiJodHRwczovL2lkcC5jdXN0b21lci1hLmV4YW1wbGUiLCJhdWQiOiJwYXJ0bmVyLWFwcCIsInN1YiI6IjBhN2UuLi4iLCJub25jZSI6IjdmQTJrelI4Li4uIiwiYXV0aF90aW1lIjoxNzkwMTUwMDAwLCJhY3IiOiJodHRwczovL2lkcC5jdXN0b21lci1hLmV4YW1wbGUvYWNyL21mYSIsImlhdCI6MTc5MDE1MDEwMCwiZXhwIjoxNzkwMTUzNzAwLCJzaWQiOiJzLTc3IiwiZW1haWwiOiJhZGFAY3VzdG9tZXItYS5leGFtcGxlIiwiZW1haWxfdmVyaWZpZWQiOnRydWV9
           {
             "iss": "https://idp.customer-a.example",
             "aud": "partner-app",
             "sub": "0a7e...",
             "nonce": "7fA2kzR8...",
             "auth_time": 1790150000,
             "acr": "https://idp.customer-a.example/acr/mfa",
             "iat": 1790150100,
             "exp": 1790153700,
             "sid": "s-77",
             "email": "ada@customer-a.example",
             "email_verified": true
           }

signature  the RS256 signature over header.payload, base64url, verified with the key kid names

The three segments travel joined by dots as one string, the id_token member of the token endpoint's JSON response, beside access_token and token_type. The header is the first segment, and alg, kid and typ live there, not among the claims. typ is JWT for an ID token when present, which Core doesn't require, and the two tokens below use it to say what they are.

Everything in those claims is personal data, and an ID token is a credential that teams log the way they would never log a password, in debug output, in error reports that attach the request, in a gateway's access log, in a trace. Never log the raw token. Log iss, sub, jti or a hash of the token, aud and exp, and nothing else. Ask for openid and only the scopes you need. Take profile data from the UserInfo endpoint after login (Core 5.3) rather than inside the token, so the token stays small and the data does not travel in a bearer artifact through the browser. Where the identity provider supports it, use pairwise sub values (Core 8.1) so the identifier itself does not correlate the user across partners. If personal data must travel in the token and must not be readable in transit, the ID token can be encrypted (a JWE), which is OpenID Connect's version of the encrypted Assertion in Listing 2. SAML's AttributeStatement has the same exposure and the same remedy.

The audience and azp rules are Core 3.1.3.7 incorporating errata set

1. The client must reject an ID token that does not list it as an

audience or that lists an audience it does not trust. azp, when present, is validated as the extension that put it there specifies. The standard claims and the open set are Core 5.1 and 5.1.2.

The logout token

Arrives by POST at the back-channel logout URI as a form parameter named logout_token. The handler is backchannel_logout, and it validates the token the way an ID token is validated before it looks for a session.

POST /oidc/backchannel-logout HTTP/1.1
Host: app.partner.example
Content-Type: application/x-www-form-urlencoded

logout_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIwMjYtMDkiLCJ0eXAiOiJsb2dvdXQrand0In0.eyJpc3MiOiJodHRwczovL2lkcC5leGFtcGxlLmNvbSIsImF1ZCI6ImNsaWVudC04ZjJhIiwiaWF0IjoxNzkwNTI0ODAwLCJleHAiOjE3OTA1MjQ5MjAsImp0aSI6ImxvLTRkMWUiLCJzaWQiOiJzLTc3IiwiZXZlbnRzIjp7Imh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvZXZlbnQvYmFja2NoYW5uZWwtbG9nb3V0Ijp7fX19.signature-omitted

header     eyJhbGciOiJSUzI1NiIsImtpZCI6IjIwMjYtMDkiLCJ0eXAiOiJsb2dvdXQrand0In0
           {"alg": "RS256", "kid": "2026-09", "typ": "logout+jwt"}

payload    eyJpc3MiOiJodHRwczovL2lkcC5leGFtcGxlLmNvbSIsImF1ZCI6ImNsaWVudC04ZjJhIiwiaWF0IjoxNzkwNTI0ODAwLCJleHAiOjE3OTA1MjQ5MjAsImp0aSI6ImxvLTRkMWUiLCJzaWQiOiJzLTc3IiwiZXZlbnRzIjp7Imh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvZXZlbnQvYmFja2NoYW5uZWwtbG9nb3V0Ijp7fX19
           {
             "iss": "https://idp.example.com",
             "aud": "client-8f2a",
             "iat": 1790524800,
             "exp": 1790524920,
             "jti": "lo-4d1e",
             "sid": "s-77",
             "events": { "http://schemas.openid.net/event/backchannel-logout": {} }
           }

signature  the RS256 signature over header.payload, base64url

Validating the token as an ID token is Back-Channel Logout section 2.6. The response is section 2.8, 200 when the session is gone (204 tolerated), 400 when the request was invalid or the logout failed, with Cache-Control: no-store. The sid at login is optional for the identity provider until the client registers backchannel_logout_session_required, which makes it required.

The launch token

The signed handoff's token, minted by the platform and carried in a POST body to the partner's launch endpoint. The handler is accept_launch_token. This one you mint, so every field is yours to define, and the checks can be stricter than you'd apply to a token from outside.

POST /launch HTTP/1.1
Host: partner.example.net
Origin: https://platform.example.com
Content-Type: application/x-www-form-urlencoded

token=eyJhbGciOiJFUzI1NiIsImtpZCI6ImxhdW5jaC0yMDI2LTA5IiwidHlwIjoibGF1bmNoK2p3dCJ9.eyJpc3MiOiJodHRwczovL3BsYXRmb3JtLmV4YW1wbGUuY29tIiwiYXVkIjoiaHR0cHM6Ly9wYXJ0bmVyLmV4YW1wbGUubmV0Iiwic3ViIjoiYTFmOWQyYzQiLCJpYXQiOjE3OTA1MjQ4MDAsImV4cCI6MTc5MDUyNDg2MCwianRpIjoiOWMyZTFmNGEtN2IzZC00ZThmLTlhMWItMmMzZDRlNWY2YTdiIiwidGFyZ2V0IjoiL3JlcG9ydHMvNDIifQ.signature-omitted

header     eyJhbGciOiJFUzI1NiIsImtpZCI6ImxhdW5jaC0yMDI2LTA5IiwidHlwIjoibGF1bmNoK2p3dCJ9
           {"alg": "ES256", "kid": "launch-2026-09", "typ": "launch+jwt"}

payload    eyJpc3MiOiJodHRwczovL3BsYXRmb3JtLmV4YW1wbGUuY29tIiwiYXVkIjoiaHR0cHM6Ly9wYXJ0bmVyLmV4YW1wbGUubmV0Iiwic3ViIjoiYTFmOWQyYzQiLCJpYXQiOjE3OTA1MjQ4MDAsImV4cCI6MTc5MDUyNDg2MCwianRpIjoiOWMyZTFmNGEtN2IzZC00ZThmLTlhMWItMmMzZDRlNWY2YTdiIiwidGFyZ2V0IjoiL3JlcG9ydHMvNDIifQ
           {
             "iss": "https://platform.example.com",
             "aud": "https://partner.example.net",
             "sub": "a1f9d2c4",
             "iat": 1790524800,
             "exp": 1790524860,
             "jti": "9c2e1f4a-7b3d-4e8f-9a1b-2c3d4e5f6a7b",
             "target": "/reports/42"
           }

signature  the ES256 signature over header.payload, base64url, verified with the platform key kid names

The POST itself is checked before the token is. The request must be a POST, and its Origin header must be the platform's own origin, which is enforced rather than logged because the platform, unlike a customer IdP, is yours.

The authentication request, for completeness

The partner sends these. Nothing refuses them on the way out, but each one is the reason a field above can be checked on the way back.

GET https://idp.customer-a.example/authorize
  ?response_type=code
  &client_id=partner-app
  &redirect_uri=https%3A%2F%2Fapp.partner.example%2Fsso%2Fcallback
  &scope=openid%20profile%20email
  &state=Q4w9pLm2...
  &nonce=7fA2kzR8...
  &code_challenge=E9Melhoa2Owv...
  &code_challenge_method=S256
  &max_age=300
  &acr_values=https%3A%2F%2Fidp.customer-a.example%2Facr%2Fmfa
  &prompt=none
  &login_hint=ada%40customer-a.example

On the wire the parameters are one query string on one line. They are split here so each can be found. A real request carries prompt=none only on the silent attempt and login_hint only when the identity provider supplied one, but both are shown so the table's rows have an example.

<samlp:AuthnRequest ID="_req5f3a" Version="2.0" IssueInstant="2026-09-27T15:58:00Z"
    Destination="https://idp.example.com/sso"
    AssertionConsumerServiceURL="https://partner.example.net/saml/acs"
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
    ForceAuthn="true" IsPassive="false">
  <saml:Issuer>https://partner.example.net</saml:Issuer>
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" AllowCreate="false"/>
  <samlp:RequestedAuthnContext Comparison="minimum">
    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

The AuthnRequest travels deflated and base64-encoded as the SAMLRequest query parameter of a redirect, with RelayState=orders as a second parameter beside it. ForceAuthn and IsPassive are both shown so the table's rows have an example. Setting both to true is allowed by Core 3.4.1 and pointless, since the identity provider may then not authenticate afresh unless it can do so silently.