An expired token
The exp claim checked against now, plus the scopes Kafka will map to an ACL principal
eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJzdmMtYXBpIiwic2NvcGUiOiJyZWFkIHdyaXRlIiwiZXhwIjoxNzAwMDAwMDAwfQ.sig
Kafka OAuth Bearer Token Decoder
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.
Paste below, or drop a file anywhere on this panel
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.
Formatted
Results
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.
Wanted a different tool?
- JWT Decoder & Inspector if the token has nothing to do with Kafka, because that reads any JWT without looking for the claims a broker needs.
Examples
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.
Which claim is the principal
sasl.oauthbearer.sub.claim.name decides the principal, and it is not always sub
eyJhbGciOiJSUzI1NiJ9.eyJjbGllbnRfaWQiOiJhcHAtMSIsInNjb3BlIjoicmVhZCIsImV4cCI6MTc5OTk5OTk5OX0.sig
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Assuming the principal comes from sub
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.
Expecting Kafka to check scopes
Kafka uses the token to establish a principal. Authorisation is ACLs, evaluated separately.
Instead:Grant ACLs to the principal. Scopes alone permit nothing.
Not handling token expiry in the client
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.
Whether Kafka will accept this token, and whether it can refresh it
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.
The refresh window is the part that goes wrong
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.
alg none is a real Kafka mode, and that is the problem
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.
The principal comes from a claim you choose
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.
The signature is not checked, and cannot be
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.
What this cannot see
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.
Related kafka tools
Kafka JAAS Config Decoder The line that stops SASL working Kafka client.properties Generator The file every CLI tool asks for Kafka Producer Config Generator No password field, on purpose Kafka SASL JAAS Generator One login module, four syntaxes Kafka Confluent Wire Format Decoder The five junk bytes in front of your payload Kafka Message Payload Decoder The first five bytes are usually not data
All 73 kafka tools