Skip to content
New issue

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

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

Already on GitHub? # to your account

OicAuthPluginTest failing against Keycloak 26.1.0 #1895

Open
basil opened this issue Jan 15, 2025 · 0 comments
Open

OicAuthPluginTest failing against Keycloak 26.1.0 #1895

basil opened this issue Jan 15, 2025 · 0 comments
Labels

Comments

@basil
Copy link
Member

basil commented Jan 15, 2025

The ATH test added in #1701, which is passing against Keycloak 26.0.8, is failing against Keycloak 26.1.0 in #1893. Documentation for this new version is here:

The Keycloak logs contain

ERROR [org.keycloak.services] KC-SERVICES0093: Invalid parameter value for: scope
WARN [org.keycloak.events] type="LOGIN_ERROR", realmId="test-realm", realmName="test-realm", clientId="jenkins", userId="null", ipAddress="172.17.0.1", error="invalid_request", reason="Invalid scopes: openid organization basic email service_account web-origins microprofile-jwt profile address roles phone offline_access acr", response_type="code", redirect_uri="http://127.0.0.1:33491/securityRealm/finishLogin", response_mode="query"

pointing to a failed call to TokenManager#isValidScope via AuthorizationEndpointChecker#checkValidScope. The failing scope is service_account, which is mentioned in the migration guide:

New client scope service_account for client_credentials grant mappers

Keycloak introduces a new client scope at the realm level called service_account which is in charge of adding the specific claims for client_credentials grant (client_id, clientHost and clientAddress) via protocol mappers. This scope will be automatically assigned to and unassigned from the client when the serviceAccountsEnabled option is set or unset in the client configuration.

Previously, the three mappers (Client Id, Client Host and Client IP Address) where added directly to the dedicated scope when the client was configured to enable service accounts, and they were never removed.

The behavior should be effectively the same for most Keycloak deployments because claims in the token are effectively same as before. You might be affected in cases when you are using a client credentials grant and you are preparing the Keycloak environment by some tooling that is manually removing or updating the three protocol mappers mentioned above. For instance, if you use an admin CLI script to enable a service-account for a client and then remove the built-in service-account protocol mappers, you may adjust your CLI to instead remove the assignment of the service_account client scope from the client instead of removing protocol mappers.

@basil basil added the bug label Jan 15, 2025
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant