GitHub user danielorf created a discussion: [OAuth 2.0] Expand OAuth 2.0 flow and token retrieval options
**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. GitHub link: https://github.com/apache/pulsar/discussions/18788 ---- This is an automatically sent email for dev@pulsar.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@pulsar.apache.org
