danielorf opened a new issue #9679: URL: https://github.com/apache/pulsar/issues/9679
**Is your enhancement request related to a problem? Please describe.** Pulsar's OAuth 2.0 flow currently only supports the [OIDC](https://ldapwiki.com/wiki/Openid-configuration) [well-known](https://tools.ietf.org/html/rfc5785) metadata configuration. Many OAuth2.0 providers do not publish their metadata to a `/.well-known/openid-configuration` endpoint and instead the auth flow starts and ends with a token-vending endpoint. Additionally, Pulsar OAuth 2.0 flow currently retrieves tokens by POSTing client creds to an OAuth 2.0 token endpoint with a JSON-only payload like [this example](https://pulsar.apache.org/docs/en/security-oauth2/#typical-original-oauth2-request-mapping) curl from Pulsar docs. Many Oauth 2.0 token vending servers expect the client creds (and other params) to be urlencoded - examples from [GCP](https://github.com/GoogleCloudPlatform/community/blob/master/tutorials/understanding-oauth2-and-deploy-a-basic-auth-srv-to-cloud-functions/index.md#client-credentials-1), [Auth0](https://auth0.com/docs/flows/call-your-api-using-the-client-credentials-flow) and [WSO2](https://docs.wso2.com/display/IS560/Client+Credentials+Grant). **Describe the solution you'd like** * A pulsar administrator must be able to configure their desired OAuth 2.0 flow from the following: * OIDC-style with `/.well-known/openid-configuration` metadata endpoint * Direct specification of the token endpoint (e.g. `$BASE_URL/oauth/token`) * A pulsar administrator must be able to configure the payload type (either [JSON](https://pulsar.apache.org/docs/en/security-oauth2/#typical-original-oauth2-request-mapping) or [urlencoded](https://auth0.com/docs/flows/call-your-api-using-the-client-credentials-flow#example-post-to-token-url)) when POSTing a token request to a token-vending endpoint using `grant_type=client_credentials` **Describe alternatives you've considered** N/A **Additional context** Examples of a common OAuth 2.0 flow that should supported by Pulsar: * [GCP](https://github.com/GoogleCloudPlatform/community/blob/master/tutorials/understanding-oauth2-and-deploy-a-basic-auth-srv-to-cloud-functions/index.md#client-credentials-1) * [Auth0](https://auth0.com/docs/flows/call-your-api-using-the-client-credentials-flow) * [WSO2](https://docs.wso2.com/display/IS560/Client+Credentials+Grant). **Additional consideration** The token public key (defined in broker config by `tokenPublicKey`) must currently be a static file or base64 encoding. Public keys can rotate and Pulsar brokers should be capable of retrieving and updating their public key without being forced to modify the `broker.conf` and restart. At a minimum, brokers should support the JWK/JWKS public format normally associated with OIDC and other OAuth 2.0 implementations. Public key rotation usually requires that multiple JWK keys are present in an array - brokers should be able to handle this multi-key situation. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
