litiliu opened a new issue, #3495: URL: https://github.com/apache/fluss/issues/3495
## Search before asking - [x] I searched in the issues and found nothing similar. ## Motivation Fluss currently supports pluggable authentication and built-in SASL/PLAIN authentication. In many production environments, service identity is managed through OAuth2/OIDC providers and clients authenticate with bearer tokens, usually JWTs. It would be useful for Fluss to support the standard SASL/OAUTHBEARER mechanism in the native Fluss RPC authentication layer. This would allow clients to authenticate with OAuth bearer tokens, and allow Fluss servers to validate those tokens and map validated claims to `FlussPrincipal` for the existing ACL authorization flow. This feature can be designed to work together with [FIP-29: (m)TLS Support](https://cwiki.apache.org/confluence/display/FLUSS/FIP-29%3A+%28m%29TLS+Support). FIP-29 keeps transport security and authentication orthogonal: TLS protects the transport, while `client.security.protocol` and `security.protocol.map` select the authentication protocol. Following that model, OAuth bearer token authentication should be introduced as a SASL mechanism. ## Solution Add support for `OAUTHBEARER` as a SASL mechanism: ```properties client.security.protocol=SASL client.security.sasl.mechanism=OAUTHBEARER ``` Server-side example: ```yaml security.protocol.map: CLIENT:SASL security.sasl.enabled.mechanisms: OAUTHBEARER security.sasl.oauthbearer.jwks.endpoint.url: https://issuer.example.com/.well-known/jwks.json security.sasl.oauthbearer.expected.issuer: https://issuer.example.com security.sasl.oauthbearer.expected.audience: fluss security.sasl.oauthbearer.principal.claim.name: sub ``` Proposed implementation direction: - Refactor the current SASL implementation so SASL mechanisms are extensible instead of hard-coding only `PLAIN`. - Preserve existing SASL/PLAIN behavior and compatibility. - Add an `OAUTHBEARER` mechanism for the native Fluss RPC authentication layer. - Add client-side token provider support. - Add server-side JWT/JWKS token validation. - Validate token signature, issuer, audience, expiration, not-before, and configurable clock skew. - Map a configurable token claim to `FlussPrincipal`. - Reuse the existing ACL authorization flow after authentication succeeds. - Add tests for successful authentication, invalid token, expired token, wrong issuer, wrong audience, and principal mapping. When TLS support from FIP-29 is available, users can run SASL/OAUTHBEARER over TLS by enabling TLS separately. Since bearer tokens are sensitive credentials, the implementation should warn or optionally fail fast when OAUTHBEARER is used without TLS. ## Anything else? Open questions for discussion: - Should the first version support only JWT/JWKS validation, or also token introspection? - Should Fluss provide built-in token providers, or only a pluggable token provider interface? - Should OAUTHBEARER over non-TLS be allowed with a warning, or rejected by default? Related design: [FIP-29: (m)TLS Support](https://cwiki.apache.org/confluence/display/FLUSS/FIP-29%3A+%28m%29TLS+Support) ## Willingness to contribute - [x] I'm willing to submit a PR! -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
