Enable Pulsar authentication for Client authentication using private_key_jwt method

[WZHMIJJ]

Search before asking

• I searched in the issues and found nothing similar.

Motivation

The motivation for this enhancement stems from the need to bolster security and efficiency in Pulsar’s client authentication. The private_key_jwt method offers a secure means for client authentication, utilizing a private key and JSON Web Token (JWT). By implementing this method, Pulsar can enhance its security framework.

Solution

The proposed solution involves enabling Pulsar authentication for Client authentication using the private_key_jwt method.

Related materials:

For further details on the private_key_jwt method, refer to the specification outlined in https://kb.authlete.com/en/s/oauth-and-openid-connect/a/client-auth-private-key-jwt

Alternatives

While evaluating alternatives, the current OAuth2 flow with client credentials (client_id and client_secret) was noted. This in our case is not an option, since we use the flow with client_assertion_type and client_assertion.

Implementing the private_key_jwt method offers a more secure and efficient alternative, reducing dependency on client_secret and providing enhanced security through private key and JWT-based authentication.

Anything else?

No response

Are you willing to submit a PR?

• I'm willing to submit a PR!

[lhotari]

How is this request different from the current JWT token support in Pulsar?
https://pulsar.apache.org/docs/3.2.x/security-jwt/

[WZHMIJJ]

Hello @lhotari,

sorry, maybe I was not clear enough. What I was talking about was the Java client we are using. We could use the option with the JWT you have mentioned, but that would mean that every time the JWT expires we would have to update it in our systems and production as well. That also normally means a restart of the application that uses this JWT token.

We use a OAuth2 authentication mechanism, but we do not have the client_id and client_secret that is being used in OAuth2 Java client implementation. In our case we use the private_key_jwt method that instead of the client_id and client_secret, uses client_assertion_type which is urn:ietf:params:oauth:client-assertion-type:jwt-bearer and client_assertion that contains information for client authentication. It must be digitally signed using a private key.

[lhotari]

Hello @lhotari,

sorry, maybe I was not clear enough. What I was talking about was the Java client we are using. We could use the option with the JWT you have mentioned, but that would mean that every time the JWT expires we would have to update it in our systems and production as well. That also normally means a restart of the application that uses this JWT token.

We use a OAuth2 authentication mechanism, but we do not have the client_id and client_secret that is being used in OAuth2 Java client implementation. In our case we use the private_key_jwt method that instead of the client_id and client_secret, uses client_assertion_type which is urn:ietf:params:oauth:client-assertion-type:jwt-bearer and client_assertion that contains information for client authentication. It must be digitally signed using a private key.

Thanks @WZHMIJJ, this is a great clarification.

[cotnic]

@lhotari is this something that would be considered to include in next versions if I tackle it?

[lhotari]

@lhotari is this something that would be considered to include in next versions if I tackle it?

@cotnic We have a community process for making the decisions. Usually new features get released in the next major version. I can help with the contribution and navigating the process if you wish to tackle this. Joining the developer mailing list and the #dev channel on Apache Pulsar Slack are good ways to stay in touch (discussions page, contact page).