[keycloak-dev] apps access to and refresh of facebook tokens

Pedro Igor Silva psilva at redhat.com
Fri Feb 27 08:21:14 EST 2015 

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, February 27, 2015 9:22:13 AM
> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> 
> On 27.2.2015 07:09, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Pedro Igor Silva" <psilva at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, February 26, 2015 8:48:43 PM
> >> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>> Cc: keycloak-dev at lists.jboss.org
> >>> Sent: Thursday, February 26, 2015 4:45:02 PM
> >>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> >>>
> >>>
> >>>
> >>> On 2/26/2015 2:04 PM, Pedro Igor Silva wrote:
> >>>> ----- Original Message -----
> >>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>> Sent: Thursday, February 26, 2015 3:41:21 PM
> >>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
> >>>>> tokens
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 2/26/2015 1:16 PM, Pedro Igor Silva wrote:
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>>> Sent: Thursday, February 26, 2015 2:09:09 PM
> >>>>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
> >>>>>>> tokens
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>>>> Sent: Thursday, February 26, 2015 12:42:19 PM
> >>>>>>>>> Subject: [keycloak-dev] apps access to and refresh of facebook
> >>>>>>>>> tokens
> >>>>>>>>>
> >>>>>>>>> At least for openid connect, I think we hashed this through on our
> >>>>>>>>> dev
> >>>>>>>>> call today.
> >>>>>>>>>
> >>>>>>>>> * There will be a Protocol Claim Mapper that can add a facebook
> >>>>>>>>> token
> >>>>>>>>> and expiration claim to the application's access token.
> >>>>>>>> I would create a specific claim set for that instead of individual
> >>>>>>>> claims.
> >>>>>>>> Something like:
> >>>>>>>>
> >>>>>>>> "k_act" : {
> >>>>>>>>         "identity-provider": {
> >>>>>>>>             "id" : "facebook",
> >>>>>>>>             "access_token": "12312312",
> >>>>>>>>             "expires": "12312321"
> >>>>>>>>         }
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> (k_act : keycloak authentication context)
> >>>>>>>>
> >>>>>>>> That way we can use this k_act for exchange information regarding
> >>>>>>>> the
> >>>>>>>> authentication context when issuing access tokens or even id tokens.
> >>>>>>>>
> >>>>>>> Yeah, token mapping be able to generate any json you want.
> >>>>>>>
> >>>>>>>>> * the refreshToken endpoint will accept a "scope" parameter.  The
> >>>>>>>>> application can then request the refresh of any external token by
> >>>>>>>>> specifying this token in the "scope parameter.
> >>>>>>>> I was thinking about adding a refreshToken endpoint to the identity
> >>>>>>>> broker.
> >>>>>>>> Isn't better ?
> >>>>>>>>
> >>>>>>> A different endpoint would require the identity broker to know if the
> >>>>>>> app has permission to request it. Also, with my idea, you can refresh
> >>>>>>> multiple things with one request.
> >>>>>>>
> >>>>>>>     From an application perspective we can provide a
> >>>>>>> KeycloakSecurityContext.refreshToken(String... scope) method, then
> >>>>>>> the
> >>>>>>> app has one place to request the refresh of one or more claims.
> >>>>>>>
> >>>>>>> i.e.
> >>>>>>>
> >>>>>>> token = context.refreshToken("facebook", "google");
> >>>>>>>
> >>>>>>> String facebookToken = token.getClaim("broker.facebook.token");
> >>>>>> I'm still not sure if this is right. Specially when using scopes for
> >>>>>> that.
> >>>>>>
> >>>>>> Regarding app permissions, know if an app has an identity provider
> >>>>>> enabled
> >>>>>> and has access to retrieve its tokens is not enough ?
> >>>>>>
> >>>>> What does "app has an identity provider enabled" mean again?
> >>>> Currently, you can enable/disable identity providers for each
> >>>> application.
> >>>> I'm also going to add another option to enable/disable token retrieval,
> >>>> as
> >>>> Stian suggested.
> >>>>
> >>> What does enable/disable entity provider per application mean?  A
> >>> disabled "facebook" would mean that a "facebook" user couldn't visit the
> >>> app?
> >> It means that an application does not supports Facebook login. We just
> >> hide
> >> the Facebook button from the login page for a particular application.
> > As we agreed on the call we need to remove that.
> +1, Keycloak is SSO. Even if "application1" doesn't support Facebook
> button on login screen, user can still login via Facebook with
> "application2" and then go back to "application1", which will
> authenticate him automatically due to SSO. So disabling Facebook button
> on login screen really doesn't prevent user from login into Keycloak
> through Facebook.

I was thinking a little bit more about that.

The user is able to login because his identity was *federated*. So, from a SSO perspective this is fine even if "application1" does not provide facebook login.

However, only users authenticating in "application2" will be able to *federate* users from facebook. This might be useful if you want to perform additional logic in "application2" right after the user is federated. For instance, show a terms & conditions page, populate an internal database with data from facebook or make "application2" to act as a portal for other apps.

> 
> Marek
> >
> > We also need to add support to selecting what apps can retrieve the token.
> >
> >>>>>> And we can also provide a single place to request refresh for multiple
> >>>>>> claims.
> >>>>>>
> >>>>> Err...that's the same thing I was suggesting.  IMO, most apps won't
> >>>>> have
> >>>>> to manually do a refresh, they can just rely on the adapter to do it
> >>>>> for
> >>>>> them.  The way I'm proposing requires no changes to adapter code and
> >>>>> the
> >>>>> user can let the adapter refresh things as appropriate.
> >>>> Sorry, what I meant is the broker being the single place to refresh
> >>>> tokens.
> >>>> And not some where else.
> >>>>
> >>>> How are you going to specify which providers the user wants to
> >>>> automatically refresh tokens ? keycloak.json ?
> >>> In admin consonle, admin would configure the app to add the facebook
> >>> token claim to the JWT access token.  When the application invokes
> >>> refreshToken, this claim will be updated if needed.  It will all be a
> >>> callback through the ProtocolMapper SPI I'm creating.
> >>>
> >>> If the application wants to refresh only one claim, then it would
> >>> specify a "scope" with the refreshToken request.
> >>>
> >>> All this refreshing would happen between one API.  Then there is nothing
> >>> broker specific for the application, only one URL to refresh everything.
> >> Ok.
> >>
> >>>
> >>> --
> >>> 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
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
>

More information about the keycloak-dev mailing list