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

Stian Thorgersen stian at redhat.com
Tue Mar 24 08:40:58 EDT 2015


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.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 24 March, 2015 1:29:33 PM
> Subject: Re: [keycloak-dev] Shouldn't external token by stored in	UserSession?
> 
> What I'm saying is that for non-social brokering, any stored token is
> invalid after logout.  The app will obtain the external token via its ID
> or access token, or it will have to go to a token exchange service,
> which, itself is access token secured.
> 
> storing an external token each login requires a write to the user database.
> 
> On 3/24/2015 8:24 AM, Bill Burke wrote:
> > Still doesn't require that the tokens be stored.
> >
> > On 3/24/2015 1:33 AM, Stian Thorgersen wrote:
> >> It's not always specific to a UserSession. The tokens obtained from a
> >> provider may be offline tokens to provide permanent access. For example
> >> if an application wants permanent access to Google and Facebook those
> >> providers can be configured with the offline scope, which would provide
> >> access even if the user didn't log-in the current session with either of
> >> those providers.
> >>
> >> A logged in user could have one token that's used to login a specific
> >> session, but also a number of other tokens that have not been used to
> >> login the specific session, but that has been used in the past, or was
> >> used when setting up the link initially.
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Monday, 23 March, 2015 3:10:56 PM
> >>> Subject: [keycloak-dev] Shouldn't external token by stored in
> >>> UserSession?
> >>>
> >>> Why is the external token stored in actual user storage
> >>> (FederatedIdentityModel).  The token is really something specific to the
> >>> UserSession and belongs there.
> >>>
> >>> Also, there may not be one single item for "external token".  For
> >>> example, OIDC has both an IDToken and access token.  The IDToken is
> >>> actually used to perform a logout according to the OIDC logout profile.
> >>>
> >>> Right now, our code is storing the AccessTokenResponse for OIDC, and the
> >>> entire login response for SAML.
> >>> --
> >>> 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
> >>>
> >
> 
> --
> 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
> 


More information about the keycloak-dev mailing list