On 12/5/2014 8:55 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> 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>
>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>> 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>
>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com>
>>>> 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