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(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>, "Marek Posolda"
<mposolda(a)redhat.com>
Cc: keycloak-dev(a)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