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

Wed Mar 4 03:07:26 EST 2015

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

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.

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