[keycloak-dev] session_state changed to ClientSession id?

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, February 20, 2015 3:30:51 PM
> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
> 
> 
> 
> On 2/20/2015 9:19 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke"
> >> <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Friday, February 20, 2015 3:14:54 PM
> >> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
> >>
> >> On 20.2.2015 14:01, Stian Thorgersen wrote:
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Friday, February 20, 2015 1:48:09 PM
> >>>> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
> >>>>
> >>>>
> >>>>
> >>>> On 2/20/2015 3:22 AM, Stian Thorgersen wrote:
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>> Sent: Thursday, February 19, 2015 8:54:48 PM
> >>>>>> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 2/19/2015 1:10 AM, Stian Thorgersen wrote:
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>>> Sent: Thursday, February 19, 2015 4:25:48 AM
> >>>>>>>> Subject: [keycloak-dev] session_state changed to ClientSession id?
> >>>>>>>>
> >>>>>>>> Can I change the session_state in the access token (and refresh
> >>>>>>>> token)
> >>>>>>>> to point to ClientSession id instead?  Right now it points to the
> >>>>>>>> user
> >>>>>>>> session id.
> >>>>>>> What's the benefits of doing that?
> >>>>>>>
> >>>>>>> It might have some impact on the Infinispan provider. For best
> >>>>>>> performance
> >>>>>>> user sessions should be retrieved by id, which we won't be able to do
> >>>>>>> if
> >>>>>>> we don't have it.
> >>>>>>>
> >>>>>> Access and refresh tokens should be associated with a client session
> >>>>>> so
> >>>>>> that we can track back an audit.  For claim mapping, I'm also allowing
> >>>>>> admins to map client session notes into the token.  There might be
> >>>>>> temporary protocol specific information stored there.
> >>>>>>
> >>>>>> I can just add a new client_session claim if needed.
> >>>>> If everything changes to lookup by client session id it should work
> >>>>> fine.
> >>>>> It would require a bit of tinkering though.
> >>>>>
> >>>>> On a related note would it make sense to create a single client session
> >>>>> per
> >>>>> client per user session? For example as the admin console doesn't store
> >>>>> tokens (and any client using keycloak.js is the same) a new client
> >>>>> session
> >>>>> is created if a user refreshes the page.
> >>>>>
> >>>> Refreshing the page nor refresh token causes a new client session to be
> >>>> submitted.  If a completely different browser is used to visit the app,
> >>>> then yes, there is a different client session.  In that case, you still
> >>>> want a new client session to be created because it would be a totally
> >>>> different HttpSession for the client.
> >>> I'm pretty sure it does. keycloak.js only keeps the token in memory and
> >>> if
> >>> you refresh the page it's lost. Then it'll redirect to the login page,
> >>> get
> >>> a new code, swap for token, etc.. We could potentially store the refresh
> >>> token in local storage, but not sure if that's a good idea.
> >> Isn't this vulnerability to some attacks? Can't some "evil" application
> >> executed from different browser tab read the token from the local storage?
> >
> > In theory, no. Local storage is only visible to js from the same domain. In
> > reality, not sure as there could be vulnerabilities in browser
> > implementations, although the same would apply to cookies as they are
> > protected by browser in the same way as local storage.
> >
> 
> Another possibility:
> 
> client crashes.  User doesn't notice, refreshes or visits a new page,
> login happens again, user doesn't know anything.  Same user session,
> different client session.

I guess we can discuss whether or not attaching so existing client session makes sense, not so sure any more. However, it would require some significant changes to do so, as we store a lot of state in the session.

So let's keep it the way it is with regards to creating a new client session for each "login". Should we store the refresh token in local storage for keycloak.js though? I think we should. I can't see that being any worse than storing it in a cookie. Browsers should protect both right and if there's an exploit either could be a problem.

> 
> Bill
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>