What it checks
JWTs, DPoP and JWKS
Algorithm confusion and alg: none. Header fields that nominate the key that
validates their own token. Lifetimes measured in weeks, string timestamps that make
validators fail open, millisecond timestamps that push expiry into the next millennium.
Personal data riding in a payload that is base64, not encryption. Tokens that will not
survive a header limit once one user accumulates enough groups. Symmetric keys published in
a document meant to be public. And each kind of token graded by its own rules: a DPoP proof,
an ID token, an access token and a logout token are different artifacts with different
required claims.
OpenID Connect and OAuth
Discovery documents advertising no PKCE, ROPC and implicit still enabled in the grant
list, and unsigned ID tokens. Authorization requests with a wildcard or look-alike redirect,
duplicated parameters, or a client secret in the browser. Redirects missing the RFC 9207
iss. Token endpoint responses and Set-Cookie headers. Trailing-slash issuer
mismatches, in the discovery document and in the token, which cost more debugging hours than
any other single character in this field. And when a redirect carries an ID token beside its
access token or code, at_hash and c_hash are actually verified,
offline — the one cryptographic check that needs no key.
SAML
Whether the assertion is signed or only the response is, and what each signature actually covers: the Reference is resolved, so a signature pointing at an element other than the one it lives in — the mechanism of signature wrapping — is reported directly, alongside multiple assertions, duplicate IDs, XPath transforms and look-alike elements in foreign namespaces. Missing audience restrictions, bearer confirmations without expiry, timestamps with no timezone, four-hour validity windows, SHA-1 digests, email addresses as durable identifiers, and certificates that expire the weekend nobody is on call. Requests, logout messages and metadata get their own rules, and redirect-binding payloads are inflated in the browser.
What it does not do
It does not verify signatures. That needs the key, and retrieving keys means network calls,
which would break the one promise this tool makes. The checkable exceptions are checked:
at_hash and c_hash need only the artifacts themselves, and they are
verified locally with WebCrypto. Everything else is about what a token says and how it is put
together, never about whether it is genuine. Verify in your own code, with the algorithm
pinned, against a key set you fetched yourself.
Why it exists
Every tool of this kind is run by a vendor, on their servers, and people paste production tokens into them all day. authlint is one static file with no build-time dependencies and no runtime ones. Save it, open it on a machine with the network unplugged, and it works exactly the same. The source is on GitHub and it is short enough to read before you trust it. There is a full guide covering every input type, what each severity means, and how to use it during an incident.
The long version
If a finding here is the first time you have met the idea behind it, the Identity Dojo is the same material at length: OAuth and OIDC flows, SAML and web SSO, tokens and JOSE, and the attacks that made each of these checks necessary. Free, no accounts, same policy on tracking.