An expired token
The exp claim checked against now, plus the scopes Kafka will map to an ACL principal
eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJzdmMtYXBpIiwic2NvcGUiOiJyZWFkIHdyaXRlIiwiZXhwIjoxNzAwMDAwMDAwfQ.sig
Decode a Kafka SASL/OAUTHBEARER token and check the claims Kafka actually reads, the expiry, and whether the lifetime leaves room for the login refresh to work. Nothing is sent anywhere and the signature is not verified, because that would need a network call.
Change these to whatever your brokers set. Many issuers do not populate
sub for a service account and use client_id or
azp, and Kafka fails authentication rather than guessing.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Decode. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
The exp claim checked against now, plus the scopes Kafka will map to an ACL principal
eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJzdmMtYXBpIiwic2NvcGUiOiJyZWFkIHdyaXRlIiwiZXhwIjoxNzAwMDAwMDAwfQ.sig
sasl.oauthbearer.sub.claim.name decides the principal, and it is not always sub
eyJhbGciOiJSUzI1NiJ9.eyJjbGllbnRfaWQiOiJhcHAtMSIsInNjb3BlIjoicmVhZCIsImV4cCI6MTc5OTk5OTk5OX0.sig
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
sasl.oauthbearer.sub.claim.name decides it, and many providers put the identity in client_id or azp instead.
Instead:Set the claim name to match the token your provider issues.
Kafka uses the token to establish a principal. Authorisation is ACLs, evaluated separately.
Instead:Grant ACLs to the principal. Scopes alone permit nothing.
The client must refresh before exp or the connection fails mid-stream, often under load when it matters.
Instead:Use a callback handler that refreshes ahead of expiry.
This site already has a JWT decoder. What is here instead is the Kafka half: the claims OAUTHBEARER reads, and the refresh arithmetic that decides whether a long-lived client stays authenticated.
Kafka renews a token at sasl.login.refresh.window.factor of its lifetime, 0.8 by default, plus up to 5 percent jitter. It clamps that so a refresh never happens sooner than sasl.login.refresh.min.period.seconds, 60, and is finished at least sasl.login.refresh.buffer.seconds, 300, before expiry. Those two add to 360 seconds, so a token with a lifetime shorter than that leaves no valid window at all: Kafka logs a warning and refreshes as early as it is permitted, and every token spends most of its life already being replaced. A five minute token looks conservative and is actually shorter than the machinery can work with.
Kafka ships OAuthBearerUnsecuredLoginCallbackHandler and OAuthBearerUnsecuredValidatorCallbackHandler for development, and they accept an unsigned token. If a broker still has the unsecured validator configured, anyone who can reach it can mint a token for any principal including a superuser, because there is nothing to forge. A token with alg none is reported as critical here for that reason: the token itself is usually harmless, and its presence means a development config reached somewhere it should not have.
Kafka reads the principal from sasl.oauthbearer.sub.claim.name, which defaults to sub. Plenty of issuers do not populate sub for a service account and use client_id or azp instead, in which case authentication fails until the broker is pointed at the right claim. You can change the claim name on this page to check what Kafka would actually see. Scope is not used for authorization at all: ACLs match on the principal, and scope only matters if a broker sets sasl.oauthbearer.expected.scope.
Verifying it needs the issuer's public key from a JWKS endpoint, which would be a network request, and this page makes none: everything happens in your browser and no part of the token is sent anywhere. So every claim shown is what the token asserts rather than something proven. A broker with sasl.oauthbearer.jwks.endpoint.url set does verify it, and will reject a token this page reads happily.
It does not know your broker's expected issuer or audience, its clock, or which callback handler it runs, so it cannot tell you the token will be accepted. It reports the claims and the arithmetic over them. Paste a token from a test issuer rather than a production one if you would rather not have a real credential in a browser tab at all, even one that stays there.