Gateway-authenticated sessions now attach a pinned identity tying them to one gateway origin.
What's wrong with this entry?
Accounts that authenticate through a gateway token now send a consent identity and a pinned fingerprint alongside the usual authorization header, tying the session to one specific gateway origin. The identity is built from a fixed gateway: tag plus the gateway's https origin, and the account identifier is hashed with SHA-256 once it passes a length threshold rather than being sent as-is.
- only applies when gateway token auth is in use; API key and OAuth sessions keep their existing consent identity path
- the hashing means the raw account identifier does not travel in the header
gateway:, organizationUuid: ${pe}${o}#${t}``
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.234
Signing back into the same account keeps a pending auto-resume
Both mention auth
-
v2.1.234
Token screen reports actual remaining validity
Both mention auth
-
v2.1.234
Setup-token login result carries the expiry
Both mention auth