[keycloak-dev] kcinit screencast

[Bill Burke]

On Thu, Mar 22, 2018 at 12:38 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> Better idea than what? The server generated key?
>

I'm saying that exchanging with a refresh-token removes the need for a
confidential client.

> 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 also don't like the idea of an admin creating a client per-user,
hence the previous idea of a persistent "device token".  Like for
instance with my iTunes app, has a menu item "Authorize this
computer".  Making purchaes still requires me to enter in my user
credentials.

The solution can already work with public clients.    The
"refresh_token" tweak I described just makes things more secure.

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

I was originally going to use your idea...You proposed it months ago...BUT...

You need to revisit how the browser handles an SSO session... Even if
the cookie is set, each confidential client in the SSO sesssion must
provide its credentials in the code to token flow to get an access
token.  Your proposal is NOT the same thing as a browser SSO session.
Your proposal basically grants a public client to be able to exchange
for any token it wants.   I hope you see the security implications of
that.

Token exchange is only one simple HTTP request, which from a client
coding perspective is not more complex than your proposal.   There is
some complexity in the admin console setup.  Currently you can grant
permission to a client to be able to exchange any token for any
client.  OR...You can have more fine grain control and explicitly
grant permission for a smaller set. IMO, this is a much better
solution than having a "special token" that can get a token to invoke
on any service.  Wouldn't your proposal require granting permission to
the public client to be able to ask for this "special token"?  Do you
see how similar your proposal is to the existing solution?

Also, token exchange is not required at all if the initial token has
permissions to invoke on any service already.  I know some people are
using Keycloak in this way.  For instance, with kubernetes+keycloak
integration, you just need Keycloak to validate the username string.
Kubernetes can grant permission to a username string to adminstrate
kubernetes.  Hope I'm making sense.

Finally, kcinit would need token exchange to be able to bridge to
external token architectures.  Login with Keycloak, exchange for an
OpenStack Keystone token so you can invoke on OpenStack services.

Thanks for the feedback.

-- 
Bill Burke
Red Hat