9:04 a.m.
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,
Sebastian
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 | Sebastian.Schuster(a)bosch-si.com
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@lists.jboss.org]
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 external mechanism.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev