[keycloak-dev] session_state changed to ClientSession id?

[Marek Posolda]

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?

Marek
>
>>
>> --
>> 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