9:37 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 24 March, 2015 2:12:45 PM
Subject: Re: [keycloak-dev] Shouldn't external token by stored in UserSession?
On 3/24/2015 8:40 AM, Stian Thorgersen wrote:
> It's not specific to social brokering, the same use-case applies to any
> IdP.
>
> There's two separate use-cases:
>
> * External IdP is used only to authenticate user (and logout) - in this
> case I don't see why the app would need the token at all
> * Application uses external token to invoke services
>
> The last use-case is the one I'm referring to and it doesn't just apply to
> social brokering (that was just the example I used). An application may
> want to invoke services secured by both the internal Keycloak and an
> external IdP. This is the use-case where the application needs to obtain
> the token from the external IdP. In this case the application quite likely
> wants to have access to invoke the services independent of what mechanism
> was used to authenticate the given session. In this case the external IdP
> could be configured with the offline scope to provide permanent access.
>
Again, right now, every brokered login *requires a user database write*.
This is unacceptable.
Untrue that the external token needs to be separate from user session.
That's just the way it was initially decided to be implemented. Flow
should be:
1. user logs in via external provide
2. external token stored in user session
3. App receives access token
The external token is either obtained by it being embedded in the app's
access or ID token (which IMO is the best way to do it), or it is
obtained via the token exchange service which *should*, IMO, require the
app's acquired access token to retrieve the external token.
Offline access should just be a clone of the original userSession,
access token, and refresh token. That way our existing architecture can
be used to manage "offline" tokens.
That's not going to work as UserSessions are lost in the case of a server
restart/failure. Offline tokens and client grants needs to be persisted permanently. For
example my phone has a offline token to my Google account and it's had it for more
than a year now. I wouldn't want to re-enable that every time Google restarts the node
that keeps my session. Maybe we need yet another (dread) storage option.
Also, finally, when the app refreshes its access token, OIDC brokered
sessions should also check the timeout of the external refresh token and
perform an external refresh if necessary. This is absolutely needed as
the external token may have been revoked.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com