You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Daniel Fonai (Jira)" <ji...@apache.org> on 2022/03/11 16:58:00 UTC
[jira] [Comment Edited] (KAFKA-13730) OAuth access token validation fails if it does not contain the "sub" claim
[ https://issues.apache.org/jira/browse/KAFKA-13730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505011#comment-17505011 ]
Daniel Fonai edited comment on KAFKA-13730 at 3/11/22, 4:57 PM:
----------------------------------------------------------------
Although it would be reasonable to expect that OAuth JWT access tokens contain the "sub" claim (as it is the case with OpenID ID tokens), I haven't found any specification requiring it:
* [OAuth 2.0 RFC|https://datatracker.ietf.org/doc/html/rfc6749] does not specify any token format.
* [JWT RFC|https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.2] states that use of "sub" claim is optional in JWTs.
* There is [RFC 9068: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens|https://www.rfc-editor.org/rfc/rfc9068.html#name-data-structure] requiring the presence of sub claim, but it is in a proposed state yet.
With this in mind, it does not seem to be interfering in any way with OAuth standards to remove this requirement. However, it would have the benefit of extending Kafka OAuth support for additional OAuth providers.
was (Author: JIRAUSER286467):
Although it would be reasonable to expect that OAuth JWT access tokens contain the "sub" claim (as it is the case with OpenID ID tokens), I haven't found any specification requiring it:
- [OAuth 2.0 RFC|https://datatracker.ietf.org/doc/html/rfc6749] does not specify any token format.
- [JWT RFC|https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.2] states that use of "sub" claim is optional in JWTs.
- There is [RFC 9068: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens|https://www.rfc-editor.org/rfc/rfc9068.html#name-data-structure] requiring the presence of sub claim, but it is in a proposed state yet.
With this in mind, it does not seem to be interfering in any way with OAuth standards to remove this requirement. However, it would have the benefit of extending Kafka OAuth support for additional OAuth providers.
> OAuth access token validation fails if it does not contain the "sub" claim
> --------------------------------------------------------------------------
>
> Key: KAFKA-13730
> URL: https://issues.apache.org/jira/browse/KAFKA-13730
> Project: Kafka
> Issue Type: Bug
> Components: clients
> Affects Versions: 3.1.0
> Reporter: Daniel Fonai
> Priority: Minor
>
> Client authentication fails, when configured to use OAuth and the JWT access token does {*}not contain the sub claim{*}. This issue was discovered while testing Kafka integration with Ping Identity OAuth server. According to Ping's [documentation|https://apidocs.pingidentity.com/pingone/devguide/v1/api/#access-tokens-and-id-tokens]:
> {quote}sub – A string that specifies the identifier for the authenticated user. This claim is not present for client_credentials tokens.
> {quote}
> In this case Kafka broker rejects the token regardless of the [sasl.oauthbearer.sub.claim.name|https://kafka.apache.org/documentation/#brokerconfigs_sasl.oauthbearer.sub.claim.name] property value.
>
> ----
>
> Steps to reproduce:
> 1. Client configuration:
> {noformat}
> security.protocol=SASL_PLAINTEXT
> sasl.mechanism=OAUTHBEARER
> sasl.login.callback.handler.class=org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerLoginCallbackHandler
> sasl.oauthbearer.token.endpoint.url=https://oauth.server.fqdn/token/endpoint
> sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required\
> clientId="kafka-client"\
> clientSecret="kafka-client-secret";
> sasl.oauthbearer.sub.claim.name=client_id # claim name for the principal to be extracted from, needed for client side validation too
> {noformat}
> 2. Broker configuration:
> {noformat}
> sasl.enabled.mechanisms=...,OAUTHBEARER
> listener.name.sasl_plaintext.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required;
> listener.name.sasl_plaintext.oauthbearer.sasl.server.callback.handler.class=org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerValidatorCallbackHandler
> sasl.oauthbearer.jwks.endpoint.url=https://oauth.server.fqdn/jwks/endpoint
> sasl.oauthbearer.expected.audience=oauth-audience # based on OAuth server setup
> sasl.oauthbearer.sub.claim.name=client_id # claim name for the principal to be extracted from
> {noformat}
> 3. Try to perform some client operation:
> {noformat}
> kafka-topics --bootstrap-server `hostname`:9092 --list --command-config oauth-client.properties
> {noformat}
> Result:
> Client authentication fails due to invalid access token.
> - client log:
> {noformat}
> [2022-03-11 16:21:20,461] ERROR [AdminClient clientId=adminclient-1] Connection to node -1 (localhost/127.0.0.1:9092) failed authentication due to: {"status":"invalid_token"} (org.apache.kafka.clients.NetworkClient)
> [2022-03-11 16:21:20,463] WARN [AdminClient clientId=adminclient-1] Metadata update failed due to authentication error (org.apache.kafka.clients.admin.internals.AdminMetadataManager)
> org.apache.kafka.common.errors.SaslAuthenticationException: {"status":"invalid_token"}
> Error while executing topic command : {"status":"invalid_token"}
> [2022-03-11 16:21:20,468] ERROR org.apache.kafka.common.errors.SaslAuthenticationException: {"status":"invalid_token"}
> (kafka.admin.TopicCommand$)
> {noformat}
> - broker log:
> {noformat}
> [2022-03-11 16:21:20,150] WARN Could not validate the access token: JWT (claims->{"client_id":"...","iss":"...","iat":1647012079,"exp":1647015679,"aud":[...],"env":"...","org":"..."}) rejected due to invalid claims or other invalid content. Additional details: [[14] No Subject (sub) claim is present.] (org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerValidatorCallbackHandler)
> org.apache.kafka.common.security.oauthbearer.secured.ValidateException: Could not validate the access token: JWT (claims->{"client_id":"...","iss":"...","iat":1647012079,"exp":1647015679,"aud":[...],"env":"...","org":"..."}) rejected due to invalid claims or other invalid content. Additional details: [[14] No Subject (sub) claim is present.]
> at org.apache.kafka.common.security.oauthbearer.secured.ValidatorAccessTokenValidator.validate(ValidatorAccessTokenValidator.java:159)
> at org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerValidatorCallbackHandler.handleValidatorCallback(OAuthBearerValidatorCallbackHandler.java:184)
> at org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerValidatorCallbackHandler.handle(OAuthBearerValidatorCallbackHandler.java:169)
> at org.apache.kafka.common.security.oauthbearer.internals.OAuthBearerSaslServer.process(OAuthBearerSaslServer.java:156)
> at org.apache.kafka.common.security.oauthbearer.internals.OAuthBearerSaslServer.evaluateResponse(OAuthBearerSaslServer.java:101)
> at org.apache.kafka.common.security.authenticator.SaslServerAuthenticator.handleSaslToken(SaslServerAuthenticator.java:451)
> at org.apache.kafka.common.security.authenticator.SaslServerAuthenticator.authenticate(SaslServerAuthenticator.java:280)
> at org.apache.kafka.common.network.KafkaChannel.prepare(KafkaChannel.java:181)
> at org.apache.kafka.common.network.Selector.pollSelectionKeys(Selector.java:543)
> at org.apache.kafka.common.network.Selector.poll(Selector.java:481)
> at kafka.network.Processor.poll(SocketServer.scala:989)
> at kafka.network.Processor.run(SocketServer.scala:892)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.jose4j.jwt.consumer.InvalidJwtException: JWT (claims->{"client_id":"...","iss":"...","iat":1647012079,"exp":1647015679,"aud":[...],"env":"...","org":"..."}) rejected due to invalid claims or other invalid content. Additional details: [[14] No Subject (sub) claim is present.]
> at org.jose4j.jwt.consumer.JwtConsumer.validate(JwtConsumer.java:466)
> at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:311)
> at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:433)
> at org.apache.kafka.common.security.oauthbearer.secured.ValidatorAccessTokenValidator.validate(ValidatorAccessTokenValidator.java:157)
> ... 12 more
> [2022-03-11 16:21:20,154] INFO [SocketServer listenerType=ZK_BROKER, nodeId=0] Failed authentication with /127.0.0.1 ({"status":"invalid_token"}) (org.apache.kafka.common.network.Selector)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)