[keycloak-dev] Federated Identity and Authentication Broker

[Bill Burke]

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?



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