[keycloak-dev] Shouldn't external token by stored in UserSession?

[Pedro Igor Silva]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, March 24, 2015 10:12:45 AM
> 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.

Considering that KC has complete control over users sessions, you can store tokens anytime you want. For instance, before the session expires.

> 
> 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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>