DEV Community

jeffrey
jeffrey

Posted on

Tokens Outlived Passwords, and Most Identity Programmes Did Not Notice

#identity #nist #tokens #postquantum

Tokens Outlived Passwords, and Most Identity Programmes Did Not Notice

NIST published the final version of Interagency Report 8587, "Protecting Tokens and Assertions from Forgery, Theft, and Misuse", on 15 September 2026, produced jointly with CISA and written for federal agencies and the cloud providers that serve them. It is a dense document about a shift that is easy to state and hard to operate: the credential that matters in a modern estate is usually not a password, and the controls built for passwords do not transfer.

What the report is actually about

The report treats tokens and assertions — SAML assertions, OIDC ID tokens, OAuth access tokens — as first-class security objects with their own lifecycle: issuance, transmission, use, verification, revocation. It catalogues five threat classes: forgery or tampering, redirection, replay, signing-key compromise, and token theft. Each has a different mitigation, and conflating them is a common source of misplaced confidence.
The signing-key class deserves separate attention. A stolen password affects one identity. A stolen token-signing key lets an attacker mint assertions that every relying party will accept, because the cryptography is genuinely valid. The report describes exactly that scenario: an actor using forged tokens derived from a single compromised commercial signing key, obtaining access to a mail system and taking tens of thousands of messages from one organisation. No amount of end-user awareness training addresses that failure mode.

Verification is more than a signature check

A recurring point in the report is that a valid signature establishes provenance, not authorisation. Verification should also test the audience, the scope, the lifetime, the unique identifier, the sender constraint, and the current access context. A token signed correctly for one service, replayed against another, passes a naive check.
Two mitigations are concrete. Sender-constrained tokens bind the credential to a client key — DPoP or mutual TLS both appear in the report — so a stolen token is useless without the corresponding private key. And backend-channel token transmission avoids placing assertions where the user agent and the browser can be induced to leak them; the front channel is convenient and exposes the token to exactly the environment the attacker already controls.
The report also addresses payload confidentiality. TLS protects the wire, not the token contents once they reach a party that logs them. Encrypting assertion payloads, via JWE or encrypted SAML assertions, limits the reconnaissance value of a token that leaks into a log aggregator.

The AI agent paragraph is short and important

NIST extends the recommendations to non-human identities, including AI agents, on the grounds that agents present signed tokens to reach systems, data, tools and APIs and therefore inherit the same obligations. The concrete advice is unremarkable in isolation and awkward in practice: shorter token lifetimes for workloads, resource scope limited to what the task needs, and sender binding where technically feasible.
The report is also candid about the limit — it does not attempt to solve agent identity management comprehensively, and defers broader IAM questions to future work. That honesty is more useful than a false framework. Teams deploying agents today are operating ahead of the guidance, which means they are also operating without an external check on their design.

PQC is a token-size problem before it is a cryptography problem

One section describes a practical consequence of post-quantum migration that is easy to miss. PQC public keys, signatures and ciphertexts are substantially larger than their elliptic-curve and RSA equivalents. In a JWT, that larger signature has to fit into an HTTP header or a cookie. Some will not. Hardware security modules may need firmware, product or architecture changes, and federations built on specific algorithms may not be able to accept the new ones without redesign.
The recommendation is to inventory where public-key cryptography sits in the token path now, and to evaluate whether the current transmission mechanism survives a PQC migration — before the migration is mandatory rather than during it.

What a defender should do on Monday

The report's structure maps cleanly onto a gap assessment:

  • Can you enumerate every issuer and signing key in your estate, and does each key have an owner, a rotation interval and a revocation path?
  • Is token verification checking audience and sender constraint, or only signature and expiry?
  • Do logs, CI/CD artefacts and build outputs contain tokens, and would you know if they did?
  • Do you have revocation working under load, or only documented?
  • Do non-human identities have lifetimes and scopes that reflect what they do, or the defaults that shipped with the platform? The shared responsibility section is worth reading with a contract in hand. Cloud providers own key custody, signing infrastructure and cryptographic hardware; customers own policy configuration, application access control, MFA settings, session management and monitoring. Most real incidents live in the seam between those two columns, which is why the report keeps returning to configuration review and continuous assessment rather than to algorithm choice.

References

Top comments (0)