[keycloak-dev] Better support authenticationSessions in multiple browser tabs

[Marek Posolda]

On 11/12/17 15:54, Bill Burke wrote:
> On Mon, Dec 4, 2017 at 2:56 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
>>
>> On 1 December 2017 at 14:53, Bill Burke <bburke at redhat.com> wrote:
>>> On Wed, Nov 29, 2017 at 9:09 AM, Marek Posolda <mposolda at redhat.com>
>>> wrote:
>>>> On 29/11/17 14:44, Stian Thorgersen wrote:
>>>>> I would target this to 3.4.2. I don't want to delay the 3.4.1 release
>>>>> if we can help it.
>>>>>
>>>>> I'd also suggest some (short if possible) random key (or a counter?!)
>>>>> rather than relying on protocol specific values. 'state' is not
>>>>> actually required in OAuth right? It's just recommended.
>>>> Yes, it's not required. And same for SAML. Was wondering about the same.
>>>> Will use the random key or counter. Thinking if counter doesn't have
>>>> some corner case issues (EG. If 2 tabs are opened concurrently after
>>>> logout and will try to use same counter value as authSession update from
>>>> tab2 won't be yet visible in tab1).
>>>>
>>> the "state" parameter IS required.  Its how the client can figure out
>>> that it initiated the login or not.
>>
>> https://tools.ietf.org/html/rfc6749#section-4.1.1
>>
>> It's RECOMMENDED
>>
> You don't remove a recommended aspect of a protocol just because its
> inconvenient to you.

AFAIK Keycloak needs to integrate with 3rd party OIDC adapters and SAML 
adapters. For our own adapters, we control everything, so we can make 
sure that "state" parameter is always send by the adapter. But for 3rd 
party adapters, we can't rely on the fact that "state" parameter is 
available in initial OIDC AuthorizationEndpoint request due the fact 
that it's just RECOMMENDED. So we can't reliably use "state" as the 
identificator of the authenticationSession tab_id (or anything else on 
the server) as it would be null in some cases. So we rather generate 
some other random ID to reference authSession.

So this is not about removing any aspects of the protocol, but rather 
the opposite - make sure that things work regardless if "state" is or 
isn't available. Or did I just misunderstood what you meant?

Marek
>
>>>
>>> I don't understand your solution...BTW, going back to auth_session_id
>>> within the URL instead of a cookie like we used to do would fix this
>>> too :).  If you're already going to add a "client-id" query parameter,
>>> why not just revert back to the old way of doing this?
>>
>> Cookie solves a lot of issues. Can't remember the details of all of them,
>> but these have been discussed several times on the mailing list this year.
>>
> Yeah, I don't remember either and I'd have to dig through emails to
> find it.  I do remember there were "back button" issues since we
> changed the session id every request.
>
>