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

Wed Mar 4 01:05:16 EST 2015

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at 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 at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 