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

[Bill Burke]

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.

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

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