[keycloak-dev] kcinit screencast

[Stian Thorgersen]

Better idea than what? The server generated key?

Does it still need a confidential client? I think that would be a blocking
point as I can't see the admin creating a client per-user that wants to use
kcinit. Nor do I think users should have to deal with yet another
credential.

I don't quite understand why the token exchange service is needed at all.
In the web browser we allow SSO logins by a simple cookie. Why not just do
something similar for kcinit? It gets a cookie (or some sort of token) that
can be used to call direct grant again. Seems so much simpler than using
token exchange here.

On 22 March 2018 at 04:01, Bill Burke <bburke at redhat.com> wrote:

> 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
>