Top-level claim under which an upstream IdP's mapped claims are recorded,
keyed by provider name: claims.federated?.["google"]?.hd.
Nothing here is authoritative for this deployment. It is the IdP's assertion,
kept verbatim so a consumer that wants a federated value can take it
deliberately, rather than receiving it merged into the envelope it also uses
for authorization.
The key is optional — read it with a presence check.mergeFederatedClaims writes it only when the provider actually mapped
at least one claim, so it is absent on a session whose provider implements no
SupportsClaimMapping, and on one whose mapClaims returned {} or a value
that is not an object. claims.federated?.[name]?.groups, never
claims.federated[name].groups. The provider key is likewise not guaranteed:
a session carries the one provider that authenticated it, not every provider
the deployment registered.
The omission is deliberate and should not be "fixed" into always writing the
key. An empty federated: {} would sit in the envelope of every session
created by a provider that maps nothing, saying only that a code path ran;
absence says "this IdP asserted nothing", which is the same absent-is-not-a-
value discipline #297 established for emailVerified.
When the key is present, it came from this merge and never from the Store:
it cannot collide with a locally-sourced claim, because extractUserClaims
picks a fixed five fields off User (email, emailVerified, name,
picture, groups) and this is not one of them.
Top-level claim under which an upstream IdP's mapped claims are recorded, keyed by provider name:
claims.federated?.["google"]?.hd.Nothing here is authoritative for this deployment. It is the IdP's assertion, kept verbatim so a consumer that wants a federated value can take it deliberately, rather than receiving it merged into the envelope it also uses for authorization.
The key is optional — read it with a presence check. mergeFederatedClaims writes it only when the provider actually mapped at least one claim, so it is absent on a session whose provider implements no
SupportsClaimMapping, and on one whosemapClaimsreturned{}or a value that is not an object.claims.federated?.[name]?.groups, neverclaims.federated[name].groups. The provider key is likewise not guaranteed: a session carries the one provider that authenticated it, not every provider the deployment registered.The omission is deliberate and should not be "fixed" into always writing the key. An empty
federated: {}would sit in the envelope of every session created by a provider that maps nothing, saying only that a code path ran; absence says "this IdP asserted nothing", which is the same absent-is-not-a- value discipline #297 established foremailVerified.When the key is present, it came from this merge and never from the Store: it cannot collide with a locally-sourced claim, because
extractUserClaimspicks a fixed five fields offUser(email,emailVerified,name,picture,groups) and this is not one of them.