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

Wed Mar 4 03:18:08 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: Wednesday, March 4, 2015 9:07:26 AM
> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> 
> On 4.3.2015 07:05, Stian Thorgersen wrote:
> >
> > ----- 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.
> yeah, 3rd party tokens will be included just if it's allowed by claims
> mapping though. So if realm supports facebook authentication, but
> application doesn't need facebook token, there is no reason to include
> facebook token in the KC access token.
> >
> >> * 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
> It could be a method on RefreshableKeycloakSecurityContext? Current
> methods like getToken on RefreshableKeycloakSecurityContext already
> works in similar way.
> 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

> 
> On non-related note, I've just noticed potential bug on
> RefreshableKeycloakSecurityContext;-)
> It seems there is no time window, so if user calls
> KeycloakSecurityContext.getToken and it returns him token, which is
> going to expire soon, the token might be expired before user invokes
> bearer REST service.

Yep, another thing I've thought about is what about if time is different on KC server and app? That's even worse in keycloak.js

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