Skip to content

feat(keycloak): add public client for browser-based SDK authentication #3050

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
marythought wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

feat(keycloak): add public client for browser-based SDK authentication #3050

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions service/cmd/keycloak_data.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -77,10 +77,23 @@ realms:
name: cli-client
serviceAccountsEnabled: false
publicClient: true
directAccessGrantsEnabled: true
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

security-medium medium

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

redirectUris:
- 'http://localhost:*'
protocolMappers:
- *customAudMapper
- client:
clientID: opentdf-public
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

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

enabled: true
name: opentdf-public
serviceAccountsEnabled: false
publicClient: true
directAccessGrantsEnabled: true
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

security-medium medium

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.

redirectUris:
- 'http://localhost:*'
- 'http://127.0.0.1:*'
Comment on lines +93 to +94
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

security-medium medium

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.

protocolMappers:
- *customAudMapper
users:
- username: sample-user
enabled: true
Expand Down
Loading