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