----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: keycloak-dev(a)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.

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

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: keycloak-dev(a)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(a)redhat.com&gt; >>> To: keycloak-dev(a)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 ?

And we can also provide a single place to request refresh for multiple claims.

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: keycloak-dev(a)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(a)redhat.com&gt; >>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>>> To: keycloak-dev(a)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.

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

From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; To: "Bill Burke" <bburke(a)redhat.com&gt; Cc: keycloak-dev(a)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(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: keycloak-dev(a)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(a)redhat.com&gt; > >> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > >> Cc: keycloak-dev(a)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(a)redhat.com&gt; > >>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > >>>> Cc: keycloak-dev(a)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(a)redhat.com&gt; > >>>>>> To: keycloak-dev(a)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 > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

I don't see the need to include the facebook token into the Keycloak token. IMO the way an application would use it is (pseudo code not real code): function callInternalEndpoint() { var internalToken = kc.getToken(); if (internalToken.isExpired()) { internalToken = kc.updateToken() } invokeRestEndpointSecuredByKc(internalToken, someData); } function callExternalEndpoint() { var facebookToken = kc.getToken("facebook"); if (facebookToken.isExpired()) { facebookToken = kc.updateToken("facebook") } invokeFacebook(facebookToken, someData); } I just don't see the need to refresh all these tokens at the same time. In the first function the internal token is required, in the second the facebook token is required. If you have more linked identities to the same user it could get even worse. For example to call Facebook you'd end up refreshing Keycloak, Facebook, Google, Twitter, etc tokens. That's a lot of unnecessary calls. Also, it would be pretty complex to do. When does for example the internal token expire? I assume that would have to be the shortest amount of time for any of the included tokens to expire. I just think we're making something quite simple into something a lot more complex for no benefit. ----- Original Message ----- > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > To: "Bill Burke" <bburke(a)redhat.com&gt; > Cc: keycloak-dev(a)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(a)redhat.com&gt; >> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>>> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>>>>>> To: keycloak-dev(a)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 >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Stian Thorgersen" <stian(a)redhat.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: "Bill Burke" <bburke(a)redhat.com&gt;, keycloak-dev(a)lists.jboss.org Sent: Friday, February 27, 2015 3:09:35 AM Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens ----- Original Message ----- > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > To: "Bill Burke" <bburke(a)redhat.com&gt; > Cc: keycloak-dev(a)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(a)redhat.com&gt; > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > Cc: keycloak-dev(a)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(a)redhat.com&gt; > > >> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > >> Cc: keycloak-dev(a)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(a)redhat.com&gt; > > >>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > >>>> Cc: keycloak-dev(a)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(a)redhat.com&gt; > > >>>>>> To: keycloak-dev(a)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. 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

From: "Marek Posolda" <mposolda(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: keycloak-dev(a)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(a)redhat.com&gt; >> To: "Bill Burke" <bburke(a)redhat.com&gt; >> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>>>> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>>>>>>> To: keycloak-dev(a)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.

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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev

----- Original Message ----- > From: "Marek Posolda" <mposolda(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Friday, February 27, 2015 9:17:57 AM > Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens > > One thing to consider: Does all identity brokers support refreshing of > tokens? For example it seems that Facebook doesn't (not 100% sure) and > instead they have long-lived access tokens. So when application wants to > refresh expired Facebook access token, it would need to browser redirect > to Keycloak with "k_idp_hint=facebook" and KC will need to redirect to > Facebook and then back to app with refreshed token. > > For minimum of HTTP requests needed, but good usability I would do it > like this: > > * Access token sent from KC to the application embeds all 3rd party > access tokens accessible by configured claims. There is risk application > doesn't need them all for particular request, but IMO it is better to > have 1 HTTP request with bigger JSON accessToken response then another > separate request from application to KC just to retrieve Facebook access > token. > > * Adapter has method on RefreshableKeycloakSecurityContext like this: > > updateThirdpartyToken("facebook", 10, httpFacade) > > which will update facebook access token just if it's going to expire in > next 10 seconds. Otherwise no network calls needed. Adapter should know > when is Facebook access token going to expire from the KC accessToken > (It should have all needed info). If token is going to expire, > HttpFacade may be needed to perform redirect to KC with idp_hint. Like I said during our meeting, different providers may have different strategies to refresh tokens even when using standard protocols. This is the case of Facebook. I think you are right, Facebook does not provides a refresh token. So we always need a redirect in order to get a fresh one if token expires or was invalidated. But I think Bill is considering that some how with his solution.

I understand the usability arguments for embedding tokens in KC access token and also the new method to refresh them. But I still think that we don't need that. IMO, each provide should implement how its tokens are refreshed. We would just need a new endpoint in broker. And just let apps invoke this endpoint in order to refresh tokens. The code for doing that is very simple and minimal without bring complexity to apps.

> Maybe identity broker should allow to specify if provider supports > refreshing tokens (in this case backend refresh from app to KC could > happen), but otherwise it would really need to go through browser > redirects IMO. > > Marek > > On 27.2.2015 07:08, Stian Thorgersen wrote: >> I don't see the need to include the facebook token into the Keycloak token. >> IMO the way an application would use it is (pseudo code not real code): >> >> function callInternalEndpoint() { >> var internalToken = kc.getToken(); >> if (internalToken.isExpired()) { >> internalToken = kc.updateToken() >> } >> invokeRestEndpointSecuredByKc(internalToken, someData); >> >> } >> >> function callExternalEndpoint() { >> var facebookToken = kc.getToken("facebook"); >> if (facebookToken.isExpired()) { >> facebookToken = kc.updateToken("facebook") >> } >> invokeFacebook(facebookToken, someData); >> } >> >> I just don't see the need to refresh all these tokens at the same time. In >> the first function the internal token is required, in the second the >> facebook token is required. If you have more linked identities to the same >> user it could get even worse. For example to call Facebook you'd end up >> refreshing Keycloak, Facebook, Google, Twitter, etc tokens. That's a lot >> of unnecessary calls. >> >> Also, it would be pretty complex to do. When does for example the internal >> token expire? I assume that would have to be the shortest amount of time >> for any of the included tokens to expire. >> >> I just think we're making something quite simple into something a lot more >> complex for no benefit. >> >> >> ----- Original Message ----- >>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>> To: "Bill Burke" <bburke(a)redhat.com&gt; >>> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>>> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>>>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>>>>> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>>>>>>>> To: keycloak-dev(a)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 >>>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >

----- Original Message ----- > From: "Marek Posolda" <mposolda(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: "Stian Thorgersen" <stian(a)redhat.com&gt;, keycloak-dev(a)lists.jboss.org > Sent: Friday, February 27, 2015 1:12:52 PM > Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens > > On 27.2.2015 14:09, Pedro Igor Silva wrote: >> ----- Original Message ----- >>> From: "Marek Posolda" <mposolda(a)redhat.com&gt; >>> To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "Pedro Igor Silva" >>> <psilva(a)redhat.com&gt; >>> Cc: keycloak-dev(a)lists.jboss.org >>> Sent: Friday, February 27, 2015 9:17:57 AM >>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens >>> >>> One thing to consider: Does all identity brokers support refreshing of >>> tokens? For example it seems that Facebook doesn't (not 100% sure) and >>> instead they have long-lived access tokens. So when application wants to >>> refresh expired Facebook access token, it would need to browser redirect >>> to Keycloak with "k_idp_hint=facebook" and KC will need to redirect to >>> Facebook and then back to app with refreshed token. >>> >>> For minimum of HTTP requests needed, but good usability I would do it >>> like this: >>> >>> * Access token sent from KC to the application embeds all 3rd party >>> access tokens accessible by configured claims. There is risk application >>> doesn't need them all for particular request, but IMO it is better to >>> have 1 HTTP request with bigger JSON accessToken response then another >>> separate request from application to KC just to retrieve Facebook access >>> token. >>> >>> * Adapter has method on RefreshableKeycloakSecurityContext like this: >>> >>> updateThirdpartyToken("facebook", 10, httpFacade) >>> >>> which will update facebook access token just if it's going to expire in >>> next 10 seconds. Otherwise no network calls needed. Adapter should know >>> when is Facebook access token going to expire from the KC accessToken >>> (It should have all needed info). If token is going to expire, >>> HttpFacade may be needed to perform redirect to KC with idp_hint. >> Like I said during our meeting, different providers may have different >> strategies to refresh tokens even when using standard protocols. This is >> the case of Facebook. I think you are right, Facebook does not provides a >> refresh token. So we always need a redirect in order to get a fresh one if >> token expires or was invalidated. But I think Bill is considering that >> some how with his solution. > Actually not sure unless I understand it bad? In first mail, Bill > mentioned adding "scope" parameter to refreshToken endpoint to specify > which 3rd party tokens to refresh. But refreshing tokens from adapter is > done through backend request. So if refreshing Facebook token requires > browser redirect, this approach won't work. Bill is full of surprises :) >> I understand the usability arguments for embedding tokens in KC access >> token and also the new method to refresh them. But I still think that we >> don't need that. >> >> IMO, each provide should implement how its tokens are refreshed. We would >> just need a new endpoint in broker. And just let apps invoke this endpoint >> in order to refresh tokens. The code for doing that is very simple and >> minimal without bring complexity to apps. > Yeah, I agree that endpoint in broker should be fine for most cases. > However how will endpoint help with refreshing Facebook access token if > they require browser redirect? Should there be config option on adapter > to specify if provider supports refreshing token through broker endpoint > or if it requires full browser redirect with "idpHint" ? > > Also adapter may need to specify: "Give me current facebook accessToken > if it's not going to expire in next 10 seconds. Otherwise refresh > facebook token". Something similar to method "updateToken" we have in > keycloak.js. I was thinking that method "updateThirdpartyToken" will > handle this for you. I think we can just start simple. Each provider has its own characteristics. If facebook requires a redirect apps just use k_idp_hint like the example app. If the provider supports backend refresh, they just use the endpoint ... In both cases, we are saving them code and time. Apps just need to deal with the KC server.

> Marek > >>> Maybe identity broker should allow to specify if provider supports >>> refreshing tokens (in this case backend refresh from app to KC could >>> happen), but otherwise it would really need to go through browser >>> redirects IMO. >>> >>> Marek >>> >>> On 27.2.2015 07:08, Stian Thorgersen wrote: >>>> I don't see the need to include the facebook token into the Keycloak >>>> token. >>>> IMO the way an application would use it is (pseudo code not real code): >>>> >>>> function callInternalEndpoint() { >>>> var internalToken = kc.getToken(); >>>> if (internalToken.isExpired()) { >>>> internalToken = kc.updateToken() >>>> } >>>> invokeRestEndpointSecuredByKc(internalToken, someData); >>>> >>>> } >>>> >>>> function callExternalEndpoint() { >>>> var facebookToken = kc.getToken("facebook"); >>>> if (facebookToken.isExpired()) { >>>> facebookToken = kc.updateToken("facebook") >>>> } >>>> invokeFacebook(facebookToken, someData); >>>> } >>>> >>>> I just don't see the need to refresh all these tokens at the same time. >>>> In >>>> the first function the internal token is required, in the second the >>>> facebook token is required. If you have more linked identities to the >>>> same >>>> user it could get even worse. For example to call Facebook you'd end up >>>> refreshing Keycloak, Facebook, Google, Twitter, etc tokens. That's a lot >>>> of unnecessary calls. >>>> >>>> Also, it would be pretty complex to do. When does for example the >>>> internal >>>> token expire? I assume that would have to be the shortest amount of time >>>> for any of the included tokens to expire. >>>> >>>> I just think we're making something quite simple into something a lot >>>> more >>>> complex for no benefit. >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>> To: "Bill Burke" <bburke(a)redhat.com&gt; >>>>> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>>> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>>>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>>>>> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>>>>>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>>>>>>> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>>>>>>>>>> To: keycloak-dev(a)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 >>>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >

On 2/27/2015 1:08 AM, Stian Thorgersen wrote: > > I just think we're making something quite simple into something a lot more complex for no benefit. > I think you are making our design more complex or less performant than it needs to be. I don't want a specific endpoint just to refresh a token for a specific broker. We're also going to want to embed nested access tokens for specific keycloak nested application invocations. I don't want a separate REST service just for that too. I also want nested REST invocations to work without having to invoke on the auth server for every request. The access token should have everything the application needs so that it can reduce traffic with the server. What if a stateless, bearer-only REST services needs the facebook token? If we're talking Javascript apps, then the backend will be entirely bearer-only stateless REST services. I don't want to require adapter specific configuration. I the vast majority of cases, I think facebook token refreshing can be handled automatically by the adapter and the auth-server-side configured token policies. We can make the facebook token policy have different configuration options to: * never to refresh the token * modify the access token's expiration to sync with the facebook one. We could add a "scope" parameter to refreshToken endpoint to give a hint to the facebook token policy on whether it needs to refresh or not. Finally, every refreshAccessToken invocation gives the auth-server the opportunity to recheck revocation policies and upgrade/downgrade the user's and application's permissions.

FYI, Facebook has 2 types of tokens: * short lived..usually last for hours * long lived usually lasts for 60 days As Marek pointed out, token refreshes require a browser redirect for Facebook. Knowing that, a REST service is not going to be able to refresh a facebook token. Let's take this further with an example. You have a "Contact-List" service that obtains a list of contacts from a social provider. You have a separate Javascript application that wants to display a list of contacts. The "Contact-List" service has to know the token and the social provider type. So given the above, the Javascript application would have to manage facebook tokens. How would that even work? It would have to be done without the Javascript app losing its state. On 2/27/2015 10:57 AM, Bill Burke wrote: > On 2/27/2015 1:08 AM, Stian Thorgersen wrote: >> >> I just think we're making something quite simple into something a lot more complex for no benefit. >> > > I think you are making our design more complex or less performant than > it needs to be. I don't want a specific endpoint just to refresh a > token for a specific broker. We're also going to want to embed nested > access tokens for specific keycloak nested application invocations. I > don't want a separate REST service just for that too. > > I also want nested REST invocations to work without having to invoke on > the auth server for every request. The access token should have > everything the application needs so that it can reduce traffic with the > server. What if a stateless, bearer-only REST services needs the > facebook token? If we're talking Javascript apps, then the backend will > be entirely bearer-only stateless REST services. > > I don't want to require adapter specific configuration. > > I the vast majority of cases, I think facebook token refreshing can be > handled automatically by the adapter and the auth-server-side configured > token policies. We can make the facebook token policy have different > configuration options to: > > * never to refresh the token > * modify the access token's expiration to sync with the facebook one. > > We could add a "scope" parameter to refreshToken endpoint to give a hint > to the facebook token policy on whether it needs to refresh or not. > > Finally, every refreshAccessToken invocation gives the auth-server the > opportunity to recheck revocation policies and upgrade/downgrade the > user's and application's permissions. >

From: "Marek Posolda" <mposolda(a)redhat.com&gt; To: "Bill Burke" <bburke(a)redhat.com&gt;, keycloak-dev(a)lists.jboss.org Sent: Monday, 2 March, 2015 1:27:20 PM Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens On 27.2.2015 18:23, Bill Burke wrote: > A few more thoughts: > > * Why wouldn't we just ask for long-lived tokens with a social login? > Why wouldn't we set the max SSO session to be shorter than the > long-lived token timeout? Then there is no refresh logic required > > * Google uses refresh tokens. > > * I don't think Twitter expires access tokens :) > > * You could handle this generically without specific broker knowledge. > AccessTokenResponse from a refreshToken call could just state that the > adapter must redirect back to the auth server in order to execute the > refresh. Yeah, however if you are brokering for example to 2nd Keycloak server, you probably don't want to redirect. As accessTokenTimeout in 2nd Keycloak would be like 1 minute, so adapter will need to redirect very often... I was thinking that identity provider can specify if it supports refreshing of tokens or not. Then: * For providers supporting refreshing token, adapter can handle it by Out-of-bound request to auth-server and auth-server can send out-of-band request to brokered provider to refresh 3rdp party token * For providers not supporting refreshing token (like Facebook) adapter would need to redirect But I don't know, maybe we don't need redirection support at all? If all other providers instead of Facebook supports refreshing tokens, we can handle all of those by OOB request and for Facebook use long-lived tokens? Marek > > On 2/27/2015 12:09 PM, Bill Burke wrote: >> FYI, Facebook has 2 types of tokens: >> >> * short lived..usually last for hours >> * long lived usually lasts for 60 days >> >> As Marek pointed out, token refreshes require a browser redirect for >> Facebook. Knowing that, a REST service is not going to be able to >> refresh a facebook token. Let's take this further with an example. >> >> You have a "Contact-List" service that obtains a list of contacts from a >> social provider. You have a separate Javascript application that wants >> to display a list of contacts. The "Contact-List" service has to know >> the token and the social provider type. >> >> So given the above, the Javascript application would have to manage >> facebook tokens. How would that even work? It would have to be done >> without the Javascript app losing its state. >> >> On 2/27/2015 10:57 AM, Bill Burke wrote: >>> On 2/27/2015 1:08 AM, Stian Thorgersen wrote: >>>> I just think we're making something quite simple into something a lot >>>> more complex for no benefit. >>>> >>> I think you are making our design more complex or less performant than >>> it needs to be. I don't want a specific endpoint just to refresh a >>> token for a specific broker. We're also going to want to embed nested >>> access tokens for specific keycloak nested application invocations. I >>> don't want a separate REST service just for that too. >>> >>> I also want nested REST invocations to work without having to invoke on >>> the auth server for every request. The access token should have >>> everything the application needs so that it can reduce traffic with the >>> server. What if a stateless, bearer-only REST services needs the >>> facebook token? If we're talking Javascript apps, then the backend will >>> be entirely bearer-only stateless REST services. >>> >>> I don't want to require adapter specific configuration. >>> >>> I the vast majority of cases, I think facebook token refreshing can be >>> handled automatically by the adapter and the auth-server-side configured >>> token policies. We can make the facebook token policy have different >>> configuration options to: >>> >>> * never to refresh the token >>> * modify the access token's expiration to sync with the facebook one. >>> >>> We could add a "scope" parameter to refreshToken endpoint to give a hint >>> to the facebook token policy on whether it needs to refresh or not. >>> >>> Finally, every refreshAccessToken invocation gives the auth-server the >>> opportunity to recheck revocation policies and upgrade/downgrade the >>> user's and application's permissions. >>> _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

I will try to summary what I had in mind. Looks like hybrid of your approaches: * KC accessToken sent to application will contain all 3rd party tokens and the info when are these 3rd party tokens going to expire * Refreshing KC accessToken from application *will not* refresh 3rd party tokens. Just sent the current 3rd party tokens back again in accessToken * Adapters will have method like "updateThirdpartyToken(String providerId, int maxRemainingExpiration)" . The semantics is similar to the method "updateToken" from keycloak.js (ie. Give me facebook token just if it's not going to expire in next 10 seconds. Otherwise trigger refresh). So refreshing of 3rd party tokens will be triggered just if current 3rd party token is really going to expire. Refreshing will happen through the endpoint on broker (if provider supports refreshing tokens) or through redirect to KC with "idpHint" . Actually I don't know if redirect support is needed as Facebook seem to be only provider, which doesn't support token refreshing, but it has support for long-lived tokens instead. This should ensure minimum amount of HTTP requests between application, auth-server and 3rd party provider. Disadvantage is bigger accessToken, but I assume that it's better to send 1 request with 10 KBytes response instead of 3 separate HTTP request with 1 KByte response each. Isn't it? Marek On 3.3.2015 05:21, Stian Thorgersen wrote: > I really think it would be a mistake to include the external tokens > into the KC token. It'll make it more complex, especially around > refreshing. I don't think it works with what the use-cases of these > tokens will be. This is for advanced use-cases and there will be > distinct parts of the application that needs the external token, which > may not even be called (for example Facebook token is only used when I > click the import contact button). A final and to me the strongest > argument is that one user account may be linked to many external > identities, this would imply that we may end up refreshing many > external token each time the internal token is refreshed, which most > likely would be pointless as I've stressed before an application will > most likely only be using one token at a time and only the token that > is required should be refreshed not all of them. > > ----- Original Message ----- >> From: "Marek Posolda" <mposolda(a)redhat.com&gt; >> To: "Bill Burke" <bburke(a)redhat.com&gt;, keycloak-dev(a)lists.jboss.org >> Sent: Monday, 2 March, 2015 1:27:20 PM >> Subject: Re: [keycloak-dev] apps access to and refresh of facebook >> tokens >> >> On 27.2.2015 18:23, Bill Burke wrote: >>> A few more thoughts: >>> >>> * Why wouldn't we just ask for long-lived tokens with a social login? >>> Why wouldn't we set the max SSO session to be shorter than the >>> long-lived token timeout? Then there is no refresh logic required >>> >>> * Google uses refresh tokens. >>> >>> * I don't think Twitter expires access tokens :) >>> >>> * You could handle this generically without specific broker knowledge. >>> AccessTokenResponse from a refreshToken call could just state that the >>> adapter must redirect back to the auth server in order to execute the >>> refresh. >> Yeah, however if you are brokering for example to 2nd Keycloak server, >> you probably don't want to redirect. As accessTokenTimeout in 2nd >> Keycloak would be like 1 minute, so adapter will need to redirect very >> often... >> >> I was thinking that identity provider can specify if it supports >> refreshing of tokens or not. Then: >> * For providers supporting refreshing token, adapter can handle it by >> Out-of-bound request to auth-server and auth-server can send out-of-band >> request to brokered provider to refresh 3rdp party token >> * For providers not supporting refreshing token (like Facebook) adapter >> would need to redirect >> >> But I don't know, maybe we don't need redirection support at all? If all >> other providers instead of Facebook supports refreshing tokens, we can >> handle all of those by OOB request and for Facebook use long-lived >> tokens? >> >> Marek >>> On 2/27/2015 12:09 PM, Bill Burke wrote: >>>> FYI, Facebook has 2 types of tokens: >>>> >>>> * short lived..usually last for hours >>>> * long lived usually lasts for 60 days >>>> >>>> As Marek pointed out, token refreshes require a browser redirect for >>>> Facebook. Knowing that, a REST service is not going to be able to >>>> refresh a facebook token. Let's take this further with an example. >>>> >>>> You have a "Contact-List" service that obtains a list of contacts >>>> from a >>>> social provider. You have a separate Javascript application that >>>> wants >>>> to display a list of contacts. The "Contact-List" service has to know >>>> the token and the social provider type. >>>> >>>> So given the above, the Javascript application would have to manage >>>> facebook tokens. How would that even work? It would have to be done >>>> without the Javascript app losing its state. >>>> >>>> On 2/27/2015 10:57 AM, Bill Burke wrote: >>>>> On 2/27/2015 1:08 AM, Stian Thorgersen wrote: >>>>>> I just think we're making something quite simple into something a >>>>>> lot >>>>>> more complex for no benefit. >>>>>> >>>>> I think you are making our design more complex or less performant >>>>> than >>>>> it needs to be. I don't want a specific endpoint just to refresh a >>>>> token for a specific broker. We're also going to want to embed >>>>> nested >>>>> access tokens for specific keycloak nested application >>>>> invocations. I >>>>> don't want a separate REST service just for that too. >>>>> >>>>> I also want nested REST invocations to work without having to >>>>> invoke on >>>>> the auth server for every request. The access token should have >>>>> everything the application needs so that it can reduce traffic >>>>> with the >>>>> server. What if a stateless, bearer-only REST services needs the >>>>> facebook token? If we're talking Javascript apps, then the >>>>> backend will >>>>> be entirely bearer-only stateless REST services. >>>>> >>>>> I don't want to require adapter specific configuration. >>>>> >>>>> I the vast majority of cases, I think facebook token refreshing >>>>> can be >>>>> handled automatically by the adapter and the auth-server-side >>>>> configured >>>>> token policies. We can make the facebook token policy have different >>>>> configuration options to: >>>>> >>>>> * never to refresh the token >>>>> * modify the access token's expiration to sync with the facebook one. >>>>> >>>>> We could add a "scope" parameter to refreshToken endpoint to give >>>>> a hint >>>>> to the facebook token policy on whether it needs to refresh or not. >>>>> >>>>> Finally, every refreshAccessToken invocation gives the auth-server >>>>> the >>>>> opportunity to recheck revocation policies and upgrade/downgrade the >>>>> user's and application's permissions. >>>>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>

----- Original Message ----- > From: "Marek Posolda" <mposolda(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: "Bill Burke" <bburke(a)redhat.com&gt;, keycloak-dev(a)lists.jboss.org > Sent: Tuesday, March 3, 2015 3:32:02 PM > Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens > > I will try to summary what I had in mind. Looks like hybrid of your > approaches: > > * KC accessToken sent to application will contain all 3rd party tokens > and the info when are these 3rd party tokens going to expire That's a good option to have, but IMO by default no 3rd party tokens should be in there and a user should be able to add those that are needed on a case-by-case. We still need to the endpoint to obtain the access token as well though. A user may want to have a clean token to invoke REST endpoints secured by Keycloak, but still be able to get the Facebook token to use in the web layer.

> * Refreshing KC accessToken from application *will not* refresh 3rd > party tokens. Just sent the current 3rd party tokens back again in > accessToken +10000 To this > * Adapters will have method like "updateThirdpartyToken(String > providerId, int maxRemainingExpiration)" . The semantics is similar to > the method "updateToken" from keycloak.js (ie. Give me facebook token > just if it's not going to expire in next 10 seconds. Otherwise trigger > refresh). So refreshing of 3rd party tokens will be triggered just if > current 3rd party token is really going to expire. Refreshing will > happen through the endpoint on broker (if provider supports refreshing > tokens) or through redirect to KC with "idpHint" . Actually I don't know > if redirect support is needed as Facebook seem to be only provider, > which doesn't support token refreshing, but it has support for > long-lived tokens instead. +1 Not sure how we'd add that to the servlet adapters though, maybe this is where JEE/CDI support comes in

> This should ensure minimum amount of HTTP requests between application, > auth-server and 3rd party provider. Disadvantage is bigger accessToken, > but I assume that it's better to send 1 request with 10 KBytes response > instead of 3 separate HTTP request with 1 KByte response each. Isn't it? Depends on the scenario. A user should be able to choose between embedding or using separate requests. > Marek > > On 3.3.2015 05:21, Stian Thorgersen wrote: >> I really think it would be a mistake to include the external tokens into >> the KC token. It'll make it more complex, especially around refreshing. I >> don't think it works with what the use-cases of these tokens will be. This >> is for advanced use-cases and there will be distinct parts of the >> application that needs the external token, which may not even be called >> (for example Facebook token is only used when I click the import contact >> button). A final and to me the strongest argument is that one user account >> may be linked to many external identities, this would imply that we may >> end up refreshing many external token each time the internal token is >> refreshed, which most likely would be pointless as I've stressed before an >> application will most likely only be using one token at a time and only >> the token that is required should be refreshed not all of them. >> >> ----- Original Message ----- >>> From: "Marek Posolda" <mposolda(a)redhat.com&gt; >>> To: "Bill Burke" <bburke(a)redhat.com&gt;, keycloak-dev(a)lists.jboss.org >>> Sent: Monday, 2 March, 2015 1:27:20 PM >>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens >>> >>> On 27.2.2015 18:23, Bill Burke wrote: >>>> A few more thoughts: >>>> >>>> * Why wouldn't we just ask for long-lived tokens with a social login? >>>> Why wouldn't we set the max SSO session to be shorter than the >>>> long-lived token timeout? Then there is no refresh logic required >>>> >>>> * Google uses refresh tokens. >>>> >>>> * I don't think Twitter expires access tokens :) >>>> >>>> * You could handle this generically without specific broker knowledge. >>>> AccessTokenResponse from a refreshToken call could just state that the >>>> adapter must redirect back to the auth server in order to execute the >>>> refresh. >>> Yeah, however if you are brokering for example to 2nd Keycloak server, >>> you probably don't want to redirect. As accessTokenTimeout in 2nd >>> Keycloak would be like 1 minute, so adapter will need to redirect very >>> often... >>> >>> I was thinking that identity provider can specify if it supports >>> refreshing of tokens or not. Then: >>> * For providers supporting refreshing token, adapter can handle it by >>> Out-of-bound request to auth-server and auth-server can send out-of-band >>> request to brokered provider to refresh 3rdp party token >>> * For providers not supporting refreshing token (like Facebook) adapter >>> would need to redirect >>> >>> But I don't know, maybe we don't need redirection support at all? If all >>> other providers instead of Facebook supports refreshing tokens, we can >>> handle all of those by OOB request and for Facebook use long-lived tokens? >>> >>> Marek >>>> On 2/27/2015 12:09 PM, Bill Burke wrote: >>>>> FYI, Facebook has 2 types of tokens: >>>>> >>>>> * short lived..usually last for hours >>>>> * long lived usually lasts for 60 days >>>>> >>>>> As Marek pointed out, token refreshes require a browser redirect for >>>>> Facebook. Knowing that, a REST service is not going to be able to >>>>> refresh a facebook token. Let's take this further with an example. >>>>> >>>>> You have a "Contact-List" service that obtains a list of contacts from a >>>>> social provider. You have a separate Javascript application that wants >>>>> to display a list of contacts. The "Contact-List" service has to know >>>>> the token and the social provider type. >>>>> >>>>> So given the above, the Javascript application would have to manage >>>>> facebook tokens. How would that even work? It would have to be done >>>>> without the Javascript app losing its state. >>>>> >>>>> On 2/27/2015 10:57 AM, Bill Burke wrote: >>>>>> On 2/27/2015 1:08 AM, Stian Thorgersen wrote: >>>>>>> I just think we're making something quite simple into something a lot >>>>>>> more complex for no benefit. >>>>>>> >>>>>> I think you are making our design more complex or less performant than >>>>>> it needs to be. I don't want a specific endpoint just to refresh a >>>>>> token for a specific broker. We're also going to want to embed nested >>>>>> access tokens for specific keycloak nested application invocations. I >>>>>> don't want a separate REST service just for that too. >>>>>> >>>>>> I also want nested REST invocations to work without having to invoke on >>>>>> the auth server for every request. The access token should have >>>>>> everything the application needs so that it can reduce traffic with the >>>>>> server. What if a stateless, bearer-only REST services needs the >>>>>> facebook token? If we're talking Javascript apps, then the backend >>>>>> will >>>>>> be entirely bearer-only stateless REST services. >>>>>> >>>>>> I don't want to require adapter specific configuration. >>>>>> >>>>>> I the vast majority of cases, I think facebook token refreshing can be >>>>>> handled automatically by the adapter and the auth-server-side >>>>>> configured >>>>>> token policies. We can make the facebook token policy have different >>>>>> configuration options to: >>>>>> >>>>>> * never to refresh the token >>>>>> * modify the access token's expiration to sync with the facebook one. >>>>>> >>>>>> We could add a "scope" parameter to refreshToken endpoint to give a >>>>>> hint >>>>>> to the facebook token policy on whether it needs to refresh or not. >>>>>> >>>>>> Finally, every refreshAccessToken invocation gives the auth-server the >>>>>> opportunity to recheck revocation policies and upgrade/downgrade the >>>>>> user's and application's permissions. >>>>>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >

> It should work fine if we need to support just refreshing by backend > requests. If we also need to support redirecting, it could be more > tricky as we would need to pass servletResponse to the method somehow as > well... -1 To refreshing by redirect