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

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.

>> >> >> 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. -- Bill Burke Red Hat