[keycloak-dev] Identity Brokering token storage and retrieval

[Stian Thorgersen]

Any comments on this?

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, 20 April, 2015 9:08:13 AM
> Subject: [keycloak-dev] Identity Brokering token storage and retrieval
> 
> We've already discussed this, but didn't come to a conclusion.
> 
> There's two separate use-cases to consider:
> 
> 1. Authentication
> 2. Offline access
> 
> For simplicity the examples below assumes OpenID Connect, but same logic
> applies to SAML.
> 
> 
> Authentication
> --------------
> In this case user authenticates using an external IdP. After the user has
> authenticated the access and refresh (if available) tokens are stored in
> user session. Tokens are automatically refreshed by Keycloak to support
> brokered log out. In this case an application can only retrieve an access
> token for the identity provider that was used to authenticate the user.
> 
> 
> Offline access
> --------------
> In this case we should add the option "offline access" to the provider
> config. When enabled we add "offline" to the requested scope. When a user
> first logs in or links through account mngmt we store the refresh token (aka
> "offline token") in the user store. As this is a long term token I don't see
> any problems using the user store for it. In this case an application can
> retrieve an access token for the identity provider that was used to
> authenticate the user, but also for an identity providers what have "offline
> access" enabled and there's an token store in the user store. One issue with
> this approach is that brokered log out doesn't work. A potential solution to
> that is that we only request offline access when linking the account, but
> during authentication don't add the offline scope and use the process from
> the first use-case.
> 
> 
> Token retrieval
> ---------------
> We add a "token service" client to Keycloak that has a "retrieve token" role
> for each provider. For an application to be able to retrieve the token the
> user has to have a role mapping on this role and the client has to have a
> scope on it as well. This results in using standard roles, scopes and
> consent screens instead of a different mechanism.
> 
> 
> For 1.2.0 we should only add support for the "Authentication" use case. I
> believe we pretty much already have this as Bill did this to support
> brokered log out. Only thing we need to change is how we manage if a client
> has access to retrieve the token or not. We should just jira the other
> use-case and add if it's requested by users.
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>