[keycloak-dev] Federated Identity and Authentication Broker

[Stian Thorgersen]

----- 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.

> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>