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

On 11/12/17 15:54, Bill Burke wrote: > > On Mon, Dec 4, 2017 at 2:56 AM, Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: >> >> >> On 1 December 2017 at 14:53, Bill Burke <bburke(a)redhat.com&gt; wrote: >>> >>> On Wed, Nov 29, 2017 at 9:09 AM, Marek Posolda <mposolda(a)redhat.com&gt; >>> 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?