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

[Stian Thorgersen]

Some comments in-line below, but I'm happy if we do the following:

* Don't include any external tokens by default, but make it easy to add those that are required. This should probably be on a per-app basis
* We can drop the token exchange service. If this is required we can add it when someone asks for it
* In the future add a feature to retrieve multiple tokens, for example a HTML5 app that invokes both Facebook and another REST service should be able not to expose the Facebook token to the REST service. I'd also like to see the token downgrade feature we discussed, or maybe the downgrade feature can support both


----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, March 4, 2015 3:11:26 PM
> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> 
> 
> 
> On 3/4/2015 3:18 AM, Stian Thorgersen wrote:
> >> 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
> >
> 
> I think you're missing a lot of how external tokens will be used and
> what environments they will be deployed into.  Futhermore I think your
> refresh and token embedding concerns are either overblown, non-existent,
> add extra complexity to the user, or hurt performance for common setups.
>   Finally, automatic refreshing needs to happen in order for logout to
> work propoerly.

Common setups won't need the external tokens, the most common use-case will be login only. So that means refreshing them all the time is a waste of external requests and more traffic which hurts performance.

> 
> * Facebook tokens can only be refreshed by redirect.
> * REST services will not be able to refresh Facebook tokens because of
> the redirect requirement
> * Facebook short-lived tokens last for hours.  Long-lived tokens last
> for 60 days.

Neither the flow I propose or the flow you propose can refresh a Facebook token if it doesn't support refreshing it, so this is an invalid argument IMO

> * Twitter tokens don't expire.
> * OIDC does not have a Single Logout Service like SAML does.  This means
> that the only way to determine if a parent OIDC Broker has logged out
> the user is to try and refresh the token.

That argument is only valid for a single token, which is the token that was used to login the current user session. This approach would only work if the external token has a shortish timeout. Also, that doesn't mean the external token has to be included in internal token.

> * REST services should not have to hit the auth-server for *EVERY REQUEST*.
> * clients should not have to manage external tokens, unless of course
> they want to.  Consider a pure OAuth example where you have a OAuth
> client that doesn't know anything about the access token format.  This
> OAuth client is talking to a REST service.  Your proposed default set up
> requires the REST service to hit the auth server every single request.

Ok, that's a very good point, but still only the external tokens that are required should be added to the token.

> * Keycloak controlled external tokens can be refreshed automatically
> without network calls.

How can Keycloak refresh external tokens without network calls?

> 
> I guess we need the token exchange service, but such a service is
> something that will only be needed in rare cases otherwise.  Letting
> Keycloak handle external tokens automatically reduces code the user has
> to write and takes request load off of the Keycloak auth server.
> 
> Your concern that refreshing tokens automatically will hurt performance
> is just bogus.  Automatic token refresh can't even be done with
> Facebook.  You don't even need token refresh for Facebook because
> long-lived tokens last 60 days.  Refresh isn't even needed for Twitter
> as their tokens last forever.  OIDC brokered tokens need to have refresh
> called to determine if the session has been logged out from the parent
> broker.

Again, that's only valid for the external token that was used to login the current session, not for all tokens. Also, it doesn't require including the external token.

I think the more common scenario is that a user logs-in with one or more external providers and the external tokens are never used, so why refresh the tokens all the time unnecessary?

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