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

[Pedro Igor Silva]

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

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