I'm not quite following if you are planning this as part of the token
exchange services or a new alternative direct grant flow?
On 14 September 2017 at 16:56, Bill Burke <bburke(a)redhat.com> wrote:
I 100% agree that direct/custom grant is not the best way to do it.
The question is, is it something we should provide as an *additional*
exchange feature? I think yes. The way I plan to secure it is as
* client must be confidential and be secured by a secret or some other
mechanism configured for that client
* client must have permission to exchange tokens for target client
* client must have permission to impersonate users
* user must be impersonateable.
On Thu, Sep 14, 2017 at 3:04 AM, Schuster Sebastian (INST/ESY1)
> While I do understand the reasons for introducing this feature. I am not
convinced a custom grant is the best way to do it. Wouldn't it be better to
expect that any external mechanism has some way of proving a user has been
authenticated and only being able to get an access token in exchange for
that proof (e.g. ID Token, Assertion, whatever). That's more in line with
the current standardization efforts on token exchange...
> Best regards,
> Mit freundlichen Grüßen / Best regards
> Dr.-Ing. Sebastian Schuster
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Schöneberger Ufer 89-91 | 10785 Berlin
| GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung:
Dr.-Ing. Rainer Kallenbach, Michael Hahn
> -----Original Message-----
> From: keycloak-dev-bounces(a)lists.jboss.org [mailto:keycloak-dev-bounces@
] On Behalf Of Bill Burke
> Sent: Mittwoch, 13. September 2017 16:52
> To: keycloak-dev <keycloak-dev(a)lists.jboss.org>
> Subject: [keycloak-dev] direct exchanges
> We have direct grants where client passes username and creds to obtain a
token for that user. We have client credentials grant to get a token for
the client itself.
> What if we had a direct exchange where the client provides user id or
username and gets a token for that user? The client does not have to
provide user credentials.
> What is the use case for this? Consider an application that is
authenticated via an external mechanism. Consider that this external
mechanism does not provide any type of token, it just authenticates a
username. This application needs to talk to services secured by Keycloak.
So, with this new direct exchange mechanism, the application only needs to
have a client account on the Keycloak server
> to obtain a token for a keycloak user. Another benefit of this is
> that Keycloak does not need to understand external token formats in
order to provide a token to a client that authenticates users by an
> There's some big security risks for this. If the client's secret is
> stolen the attacker would be able to mint token for any user. This
> is somewhat mitigated in two ways:
> a) If the token is minted for the client, the scope of the token can be
limited, i.e. role mappings limited
> b) if the client is asking for a different audience (a different
> client) the client can be limited on the audience it can ask for. (we
already do this check for client to client token exchange).
> Bill Burke
> Red Hat
> keycloak-dev mailing list
> keycloak-dev mailing list
keycloak-dev mailing list