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

Tue Mar 3 10:59:43 EST 2015

Stateless, bearer-only, REST services will often need a fully populated 
access token so that they don't have to hit the auth-server each and 
every request they process.

I also see that these REST services will often aggregate calls to other 
services.  Because these services might be a mix of trusted, 
semi-trusted, untrusted, and anonymous, we will the ability to craft 
specific access tokens that contain more or less information.  Access 
tokens could even be encrypted and specific to each client.

Once I get my claim mappers in place, we can set up any policy we want 
and the user can choose exactly what they want placed in a token.

On 3/3/2015 9:32 AM, Marek Posolda wrote:
> 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 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
>>>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com