keycloak / keycloak

Open Source Identity and Access Management For Modern Applications and Services
https://www.keycloak.org
Apache License 2.0
22.29k stars 6.61k forks source link

Revise client authentication requirement for token-exchange #31550

Open thomasdarimont opened 1 month ago

thomasdarimont commented 1 month ago

Description

Find a way to allow users to use token-exchange also with a public clients in a secure way.

Discussion

No response

Motivation

Some use-cases like "down-scoping" a current access token for a public client require additional infrastructure like a backend for frontend (BFF), these architectures could be simplified if we would allow / support token-exchange for (unauthenticated) public clients.

One option might be to only allow the downscoping use-case for a public client (exchanging an access token with a new one with less scopes than the original, but for the same user and the same client) to call a backend API.

We could also support the user impersonation use-case and allow the token-exchange of an access token for user A with a new one for user B (but only for the same client).

Details

Currently the token-exchange implementation of Keycloak can only be used with confidential clients. The RFC8693 says "Client authentication to the authorization server is done using the normal mechanisms provided by OAuth 2.0. Section 2.3.1 of [RFC6749] defines password-based authentication of the client, however, client authentication is extensible and other mechanisms are possible. For example, [RFC7523] defines client authentication using bearer JSON Web Tokens (JWTs) [JWT]. The supported methods of client authentication and whether or not to allow unauthenticated or unidentified clients are deployment decisions that are at the discretion of the authorization server. Note that omitting client authentication allows for a compromised token to be leveraged via an STS into other tokens by anyone possessing the compromised token. Thus, client authentication allows for additional authorization checks by the STS as to which entities are permitted to impersonate or receive delegations from other entities."

Token-Exchange is not limited to only confidential clients by the spec, however, the authorization server may impose its own policies requiring confidential clients for certain operations.

c-thiel commented 1 week ago

+1 to support public clients. I was really surprised that this wasn't possible. As a workaround we are using two client ids now (one private one public) and accept tokens to either.