[keycloak-dev] kcinit screencast

[Bill Burke]

On Wed, Mar 21, 2018 at 10:45 PM, Bill Burke <bburke at redhat.com> wrote:
> 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.
>

Thought of a better idea...Public clients can only exchange a refresh
token.  The refresh token is used as a client credential.  Token
exchange endpoint looks at the passed in client_id.  it must match the
issuedFor claim in the refresh token.


-- 
Bill Burke
Red Hat