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

[Bill Burke]

On 2/26/2015 2:04 PM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, February 26, 2015 3:41:21 PM
>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
>>
>>
>>
>> On 2/26/2015 1:16 PM, Pedro Igor Silva wrote:
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, February 26, 2015 2:09:09 PM
>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
>>>>
>>>>
>>>>
>>>> On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Thursday, February 26, 2015 12:42:19 PM
>>>>>> Subject: [keycloak-dev] apps access to and refresh of facebook tokens
>>>>>>
>>>>>> At least for openid connect, I think we hashed this through on our dev
>>>>>> call today.
>>>>>>
>>>>>> * There will be a Protocol Claim Mapper that can add a facebook token
>>>>>> and expiration claim to the application's access token.
>>>>>
>>>>> I would create a specific claim set for that instead of individual
>>>>> claims.
>>>>> Something like:
>>>>>
>>>>> "k_act" : {
>>>>>        "identity-provider": {
>>>>>            "id" : "facebook",
>>>>>            "access_token": "12312312",
>>>>>            "expires": "12312321"
>>>>>        }
>>>>> }
>>>>>
>>>>> (k_act : keycloak authentication context)
>>>>>
>>>>> That way we can use this k_act for exchange information regarding the
>>>>> authentication context when issuing access tokens or even id tokens.
>>>>>
>>>>
>>>> Yeah, token mapping be able to generate any json you want.
>>>>
>>>>>> * the refreshToken endpoint will accept a "scope" parameter.  The
>>>>>> application can then request the refresh of any external token by
>>>>>> specifying this token in the "scope parameter.
>>>>>
>>>>> I was thinking about adding a refreshToken endpoint to the identity
>>>>> broker.
>>>>> Isn't better ?
>>>>>
>>>>
>>>> A different endpoint would require the identity broker to know if the
>>>> app has permission to request it. Also, with my idea, you can refresh
>>>> multiple things with one request.
>>>>
>>>>    From an application perspective we can provide a
>>>> KeycloakSecurityContext.refreshToken(String... scope) method, then the
>>>> app has one place to request the refresh of one or more claims.
>>>>
>>>> i.e.
>>>>
>>>> token = context.refreshToken("facebook", "google");
>>>>
>>>> String facebookToken = token.getClaim("broker.facebook.token");
>>>
>>> I'm still not sure if this is right. Specially when using scopes for that.
>>>
>>> Regarding app permissions, know if an app has an identity provider enabled
>>> and has access to retrieve its tokens is not enough ?
>>>
>>
>> What does "app has an identity provider enabled" mean again?
>
> Currently, you can enable/disable identity providers for each application. I'm also going to add another option to enable/disable token retrieval, as Stian suggested.
>

What does enable/disable entity provider per application mean?  A 
disabled "facebook" would mean that a "facebook" user couldn't visit the 
app?

>>
>>> And we can also provide a single place to request refresh for multiple
>>> claims.
>>>
>>
>> Err...that's the same thing I was suggesting.  IMO, most apps won't have
>> to manually do a refresh, they can just rely on the adapter to do it for
>> them.  The way I'm proposing requires no changes to adapter code and the
>> user can let the adapter refresh things as appropriate.
>
> Sorry, what I meant is the broker being the single place to refresh tokens. And not some where else.
>
> How are you going to specify which providers the user wants to automatically refresh tokens ? keycloak.json ?

In admin consonle, admin would configure the app to add the facebook 
token claim to the JWT access token.  When the application invokes 
refreshToken, this claim will be updated if needed.  It will all be a 
callback through the ProtocolMapper SPI I'm creating.

If the application wants to refresh only one claim, then it would 
specify a "scope" with the refreshToken request.

All this refreshing would happen between one API.  Then there is nothing 
broker specific for the application, only one URL to refresh everything.


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