Re: [keycloak-dev] session_state changed to ClientSession id?

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)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(a)redhat.com&gt; >>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>>> To: keycloak-dev(a)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.

> > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev