Re: [keycloak-dev] Federated Identity and Authentication Broker

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)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(a)redhat.com&gt; >> To: keycloak-dev(a)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(a)redhat.com&gt; >>>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>> Cc: keycloak-dev(a)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.

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