[keycloak-dev] Federated Identity and Authentication Broker

[Bill Burke]

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.


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