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

[Bill Burke]

On Mon, Dec 11, 2017 at 10:22 AM, Marek Posolda <mposolda at redhat.com> wrote:
> 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?
>

I misunderstood before what was going on with State parameter.  I
thought you were talking about removing it.



-- 
Bill Burke
Red Hat