Federated identity

RFC 6749 section 2.1 types a client on one property: whether it can keep its credentials confidential. Server-side code can. An installed mobile app cannot, so it is public — a secret shipped inside it is readable by whoever installs it.

The authorization code grant keeps the resource owner's password at the authorization server. The user authenticates there, and the client receives only a short-lived authorization code, which it exchanges on a back channel for a scoped access token.

RFC 8252 keeps the authorization request in an external user-agent because an embedded web view runs inside the application: the application can observe what is typed into it, including the resource owner's credentials, and it shares no signed-in session with the browser.

PKCE stops authorization-code interception. An attacker who captures the code as it travels back through the browser cannot redeem it, because the token request must also carry a code_verifier that only the application which started the flow holds.

Exact string matching is what ties an issued authorization code to the application that asked for it. Any looser rule - prefix, substring or wildcard - lets an attacker steer the response to a destination the client never registered.

Remove any terminating slash from the issuer URL, then concatenate /.well-known/openid-configuration to it. The JSON object returned carries issuer, authorization_endpoint, token_endpoint, userinfo_endpoint and jwks_uri, so one configured value yields every address the flow needs.

A single short-lived authorization code, and nothing else. With response_type=code the provider puts no ID token and no access token on the redirect; the client exchanges the code at the token endpoint and receives both there.

An OpenID Connect ID token is a signed statement, addressed to the client that asked, that a named user just authenticated at a named issuer. An access token authorises an API call and says nothing about who signed in.

An authorization request becomes an OpenID Connect authentication request only when its scope parameter includes the value openid. That value makes the provider issue an ID token; without it the exchange is plain OAuth 2.0 authorization.

The UserInfo endpoint is an OAuth 2.0 protected resource. The relying party presents the access token from the same sign-in as a bearer credential over TLS, and receives a JSON object of claims about that end user.

iss names who issued the token, sub the principal the claims describe, aud the intended recipients, exp the moment from which it must not be accepted, and iat when it was issued. All are optional registered claim names.

A JWS is signed but not encrypted: anyone holding it can decode and read the claims, and the signature only proves they were not altered. A JWE encrypts the payload, so only a holder of the decryption key can read it.

Signing protects integrity, not confidentiality. A JWS payload is only Base64url-encoded, so anyone holding the token — or reading a log, a proxy trace or browser storage — can decode every claim. Secrets belong outside the token or inside an encrypted one.

Base64url is an encoding, not encryption, and a signature protects integrity rather than confidentiality. Anyone holding a signed JWT can decode its claims, so it must carry no secrets and no data the holder should not see.

A signed JWT is three Base64url segments joined by dots: a JOSE header naming the algorithm and key, a JSON claims payload, and a signature computed over the first two segments.

A browser will not originate a cross-site POST on its own, so the sender returns a page holding a form aimed at the recipient's endpoint and submits it by script. The form carries the base64-encoded SAML message in a hidden control named SAMLRequest or SAMLResponse.

The identity provider authenticates the person and issues a signed SAML assertion; the service provider receives it at its AssertionConsumerService endpoint and must validate it before creating its own application session.

SP-initiated login starts at the service provider, which sends the browser to the identity provider carrying an AuthnRequest message. IdP-initiated login starts at the identity provider, which sends an unsolicited Response the service provider never asked for.

AudienceRestriction names, by entityID URI, the parties the assertion is addressed to; anyone not named must not rely on it. With none present, every service provider that receives a copy can read it as addressed to itself, and nothing in the document contradicts that.

The Conditions NotOnOrAfter bounds how long the assertion is a valid statement at all; the SubjectConfirmationData NotOnOrAfter bounds only how long this bearer may present it for delivery. They are two separate clocks and both must hold.

Federating login between organisations means each organisation's own identity provider authenticates its own people and vouches for them to the other's application. The application stops issuing credentials and storing passwords for those users, and instead validates a signed statement about them.

Both members must already trust the same third party, a federation Trust Anchor, and each must publish a signed statement about itself under it. The anchor's attestation, not a private agreement between the two, is what makes the other side acceptable.

It makes three component claims — a proofing value, a primary-credential-usage value and an assertion-presentation value — whose meanings come from the trust framework named alongside it. The missing M component is not a zero: no claim is made about credential management.

SAML 2.0 delivers an XML assertion with an XML Signature over it, so the relying side needs an XML toolchain that canonicalises and verifies documents. OpenID Connect delivers a JWT verified with a JOSE library against a published key set. That difference decides which platforms can cheaply be a relying party.

Component values are defined per trust framework and carry no ordinal or subsumptive meaning, so identical strings from two frameworks are not comparable. Build a mapping table per framework, keyed by its trustmark, that translates each partner's claims into your own policy decisions.