[keycloak-dev] session_state changed to ClientSession id?

[Bill Burke]

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.

Bill

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