[keycloak-dev] kcinit screencast

[Bill Burke]

On Wed, Mar 21, 2018 at 10:08 AM, Stian Thorgersen <sthorger at 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 at redhat.com> wrote:
>>
>> http://youtu.be/uwkggE25TjM?hd=1
>>
>> --
>> Bill Burke
>> Red Hat
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>



-- 
Bill Burke
Red Hat