feat(keycloak): add public client for browser-based SDK authentication#3050
feat(keycloak): add public client for browser-based SDK authentication#3050marythought wants to merge 1 commit intomainfrom
Conversation
Add opentdf-public client and enable direct access grants to support browser-based JavaScript SDK quickstart authentication flow. Signed-off-by: Mary Dickson <mary.dickson@virtru.com>
Summary of ChangesHello @marythought, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces configurations to Keycloak to facilitate browser-based JavaScript SDK authentication for local development and testing environments. By adding a new public client and enabling direct access grants on an existing client, it allows the use of password grant flows, which are necessary for browser-based SDKs that cannot securely handle client secrets. The changes are carefully scoped to minimize security risks by restricting usage to localhost and emphasizing non-production contexts. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Keycloak grants access, Tokens flow, a secure path, Devs build, code takes flight. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new public Keycloak client opentdf-public and enables direct access grants for it and the existing cli-client to support browser-based SDK authentication for local development. However, it introduces security-sensitive changes by enabling the deprecated Resource Owner Password Credentials (ROPC) grant type and using wildcard redirect URIs for public clients. These are insecure authentication patterns that should be avoided in production, with ROPC being superseded by more secure flows like Authorization Code Flow with PKCE. To mitigate risks, it's crucial to add explicit warnings in the keycloak_data.yaml configuration file, as suggested in the comments, to prevent accidental use of these less-secure settings in production environments.
| protocolMappers: | ||
| - *customAudMapper | ||
| - client: | ||
| clientID: opentdf-public |
There was a problem hiding this comment.
Similar to the cli-client, it's important to add a warning comment for this new opentdf-public client. This makes it clear that enabling directAccessGrantsEnabled is for local testing/quickstart purposes only and should not be used in production due to security risks associated with the password grant flow.
# WARNING: This client is for browser-based SDK quickstarts and local testing only.
# It uses the less-secure password grant flow. Do not use in production.
clientID: opentdf-public| name: cli-client | ||
| serviceAccountsEnabled: false | ||
| publicClient: true | ||
| directAccessGrantsEnabled: true |
There was a problem hiding this comment.
Enabling directAccessGrantsEnabled (Resource Owner Password Credentials grant) is discouraged by OAuth 2.0 security best practices as it increases the risk of credential theft and bypasses MFA. While intended for local development, it's crucial to add a warning comment here to prevent accidental enabling in production environments. For production, the Authorization Code Flow with PKCE is the recommended secure alternative.
# WARNING: Enables the less-secure password grant flow for local development.
# Do not enable in production environments.
directAccessGrantsEnabled: true| name: opentdf-public | ||
| serviceAccountsEnabled: false | ||
| publicClient: true | ||
| directAccessGrantsEnabled: true |
There was a problem hiding this comment.
Enabling directAccessGrantsEnabled (Resource Owner Password Credentials grant) for the opentdf-public client introduces security risks by allowing the client to handle user passwords directly. This grant type is deprecated in the OAuth 2.1 specification and should be avoided. For public clients like browser-based SDKs, Authorization Code Flow with PKCE should be used instead to ensure user credentials are not exposed to the client application.
| - 'http://localhost:*' | ||
| - 'http://127.0.0.1:*' |
There was a problem hiding this comment.
The use of wildcards in redirectUris (e.g., http://localhost:*) is insecure as it allows an attacker to redirect authorization codes to any port on the host. Although restricted to localhost and 127.0.0.1, this could still be exploited if a malicious process on the user's machine intercepts the code. It is a best practice to register exact redirect URIs. If multiple ports are required for development, they should be listed explicitly.
Benchmark results, click to expandBenchmark authorization.GetDecisions Results:
Benchmark authorization.v2.GetMultiResourceDecision Results:
Benchmark Statistics
Bulk Benchmark Results
TDF3 Benchmark Results:
|
1 participant
Add opentdf-public client and enable direct access grants to support browser-based JavaScript SDK quickstart authentication flow.
Proposed Changes
localhost:*and127.0.0.1:*)This enables the JavaScript SDK quickstart to obtain refresh tokens via password grant for local development/testing, as the browser-based SDK cannot use client credentials (client secrets) for security reasons.
Is it a security change? Yes - it enables a less secure OAuth flow (password grant).
However, the following factors mitigate the risk:
Checklist
Testing Instructions