On Wed, Mar 21, 2018 at 10:08 AM, Stian Thorgersen <sthorger(a)redhat.com> wrote:
That's really nice. First time I see oauth done well from the
command line.
I think it could do with some more newlines in places to space the outputs a
bit more apart. Minor thing though.
I fixed some of those issues. reading in masked input (password) was
eating the newline.
Thinking a bit about the confidential client when invoking the token
exchange. As kcinit really is a public client how do you envision folks
would use that?
That isn't true. kcinit can be a confidential client. A client
secret isa 2nd factor credential which grants the machine permission
to request a login. I was thinking of the idea of a "device token"
that could be used as the client-secret. A client could have many
device tokens that could be created/revoked. Then you just create a
device token for kcinit for the machine you install it on.
Most admins will probably be lazy though and just have a public client
or a client secret that is shared by everybody.
Could another option be to use the ID token (or some other special
SSO login
token) to allow obtaining tokens for different clients?
What you're describing is token exchange.. :-)
1. kcinit login - obtains an access token from master client
2. kcinit token app - exchanges access token retrieved in step 1
So, the access token received in step one acts as an "ID Token", with
the caveat that the realm admin can control which applications you can
exchange a token for.
I was thinking something like "kcinit login" obtains the ID
token (or the
other SSO login token aka something to replace the SSO cookie on web). It
could also request an offline session to have the tool connected long term
(i.e. for a bot or something). Then next time you want to obtain a token for
a specific client it can just pass this SSO login token instead of user
creds to retrieve tokens for that app.
offline access does the same thing doesn't it?
One question which is relevant if you use token exchange as well as
if
there's some sort of SSO login token is how do we prevent an application
from obtaining a token for another app. App A for instance could just invoke
kcinit internally without the user knowing about it to obtain token for App
B.
Do you mean a rogue command line application? Or the remote
application? If you mean a remote application, then you don't use a
public client for kcinit. If you don't use a public client for
kcinit, then the app won't be able to exchange because it won't have
permission to.... Hmmm...I wonder if we could have the server generate
a key. Stuff a hash from that key into the token. Return the key
used within AccessTokenResponse. Then the public client uses this key
as a client credential when requesting an exchange. Then rogue remote
applications can't impersonate the public client to exchange the
token, because it won't have the temporary key.
On 21 March 2018 at 00:03, Bill Burke <bburke(a)redhat.com> wrote:
>
>
http://youtu.be/uwkggE25TjM?hd=1
>
> --
> Bill Burke
> Red Hat
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
Red Hat