[keycloak-dev] Federated Identity and Authentication Broker

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 5 December, 2014 3:01:16 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> 
> 
> 
> On 12/5/2014 8:55 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 5 December, 2014 2:45:57 PM
> >> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> >>
> >>
> >>
> >> On 12/5/2014 8:43 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Friday, 5 December, 2014 2:36:14 PM
> >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>> Sent: Friday, December 5, 2014 10:59:08 AM
> >>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
> >>>>> Broker
> >>>>>
> >>>>> Another related thing. We've had a few people ask to be able to login
> >>>>> to
> >>>>> Keycloak on mobiles using the native social login mechanism.
> >>>>>
> >>>>> I think the best way to do that is to use the direct grant api and make
> >>>>> it
> >>>>> possible to call that endpoint passing a IdP id and a token instead of
> >>>>> username and password.
> >>>>>
> >>>>> WDYT?
> >>>>
> >>>> The broker endpoint expects the idp id in order to start the
> >>>> authentication
> >>>> process. Today, the endpoint also expects KCs authorization code in
> >>>> order
> >>>> to
> >>>> validate requests from clients and use it as a state to validate
> >>>> responses
> >>>> from the trusted idps.
> >>>>
> >>>> This authorization code is a blocker for this use case, given that
> >>>> mobile
> >>>> don't have this code and just want to start the authentication.
> >>>>
> >>>> A possible solution would be to change the broker to also accept a
> >>>> client_id
> >>>> to reference the mobile app and perform some validations based on that.
> >>>> Something like that:
> >>>>
> >>>> 1) Mobile displays a Facebook button
> >>>> 2) User clicks the button and mobile sends a request to KC Broker with
> >>>> the
> >>>> idp id and his client_id.
> >>>> 3) KC Broker checks if the client_id is valid and creates a temporary
> >>>> authorization code.
> >>>> 4) KC Broker redirect mobile to the chosen IdP to perform
> >>>> authentication.
> >>>> 5) KC Broker receives a response from the IdP, generate its own token
> >>>> and
> >>>> send it back to mobile
> >>>>
> >>>> Makes sense ?
> >>>
> >>> No that's not the flow I had in mind. Basically the mobile app
> >>> authenticates with Facebook through the native mechanisms. The app then
> >>> has an access token, which it would send to Keycloak on the direct grant
> >>> api to obtain a Keycloak token.
> >>>
> >>> Same for other identity providers, the assumption is the app has an out
> >>> of
> >>> bounds mechanism to obtain an access token, which is then sent to
> >>> Keycloak
> >>> over the direct grant api.
> >>>
> >>
> >> How would/could that work exactly?  Do social providers sign the token
> >> somehow?  Can the token be verified?
> >
> > I think we should invoke the IdP to verify the token rather than verify it
> > locally.
> >
> > All the social providers we have at the moment first retrieve a token, then
> > use it to obtain the user profile. I assumed we'd just skip the first step
> > and just use the supplied token to retrieve the user profile.
> >
> > For OpenID Connect providers there's the UserInfo endpoint that can be
> > used. That'll both verify the token as well as provide us with the user
> > profile.
> >
> > Not sure about SAML.
> >
> Keycloak doesn't even need to be involved unless you want an access token.
> 
> IMO, define a solid way on how you would like it to look and work.  Then
> worry later whether or not a specification fits the model.

It basically boils down to not everyone wants to use the recommended login flows we have. With our login screen a social buttons on the page. There's at least 3 users that's asked how they can integrate with the native login experiences provided by Google and Facebook on mobiles to login to Keycloak.

They'll have a token from Facebook or Google, but need a token from Keycloak to be able to invoke their own apps.

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>