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