[Openid-specs-ab] Feedback on OpenID Connect Session Management
ve7jtb at ve7jtb.com
Mon May 30 22:32:53 UTC 2016
I suppose some other hash could have been used besides S256. It however is probably not worth the trouble to make it configurable.
I think it was Google that came up with the S256 requirement.
Work on that session management spec has largely stalled. Google who originally proposed it, built something similar but incompatible.
I believe Microsoft is the only one to have widely implemented it. I think they are relatively happy with it in Azure.
Google is now proposing a integrated login/ session management API. http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20151116/005865.html <http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20151116/005865.html>
I am personally mostly concentrating on the backchannel logout spec as that can be used with native apps where the front channel ones won’t work.
As we know from SAML logout is harder than login. The front channel specs are best effort and are known to fail in lots of circumstances.
> On Apr 4, 2016, at 11:12 AM, Thomas Broyer <t.broyer at gmail.com> wrote:
> Hi all,
> I've been implementing Session Management over the passed days (both OP and RP), and have some feedback/questions about the current draft.
> §3 Creating and Updating Sessions
> > The generation of suitable Session State values is specified in Section 4.2, and is based on
> > a salted cryptographic hash of Client ID, origin URL, and OP browser state.
> I (somewhat) understand the need for a "salt" (as briefly described in §4.2 “incorporate sufficient randomness in the form of a salt so as to prevent identification of an End-User across successive calls to the OP's Authorization Endpoint.”; see below) but not really why it'd need to be a "cryptographic hash". Note that the only other mention of "crypto" is "CryptoJS" in the non-normative example code in §4.2, and there's no other mention of "hash" in the whole document.
> I “naively” implemented Session Management using the same algorithm as the non-normative example code ("sha256(client_id SP origin SP browser state SP salt) '.' salt") but I really wonder why it'd need such demanding algorithm as a cryptographic hash like SHA-256).
> Couldn't a basic, I don't know, maybe, XOR be used?
> I mean, everything's "public" here: the code for the OP iframe, the browser state (in the sense that it's known to the browser), the session state, the client_id, the RP origin; and while crypto in the browser is relatively widely available (this is assuming people run uptodate browsers; which is not the case: there are still a lot of people with outdated and now-unsupported Internet Explorer versions, or outdated versions of Firefox, because they installed "portable" versions to bypass privilege restrictions set by IT departments: one of our customers filed an issue about a rendering glitch in Firefox… 17!), it may not be worth the effort.
> §4.2 OP iframe
> > The RP MUST assign an id attribute to the iframe so that it can address it, as described above.
> This is a technical implementation detail, it doesn't need a MUST; ad if the RP wants to do things differently (e.g. the iframe is created by a script and either stored in a global variable –accessible from the RP iframe– or passed as argument to a function called in the RP iframe's browsing context).
> > The OP iframe MUST enforce that the caller has the same origin as its parent frame.
> > It MUST reject postMessage requests from any other source origin.
> How do you do that? window.parent.location.href is blocked by the same-origin policy. There's document.referrer but while the value will generally be equivalent to the parent window's location, this is not guaranteed.
> The non-normative example code doesn't do that check BTW.
> Anyway, to be able to postMessage to the iframe, the script needs to have a "handle" on it, which means it runs in the same origin as the parent window (to get access to the iframe in the document), so it's not really worth checking, right?
> I actually wondered at some point why there'd need to be an RP iframe. It's really only useful for the "hidden redirects", but that doesn't mean the postMessage must come from the iframe; the iframe could communicate with the parent window (same origin anyway, as the RP iframe needs to be able to address the OP iframe) which communicates with the OP iframe using postMessage (the RP iframe could even be dynamically created only when needed –in response to a "changed" response message from the OP iframe, to redirect to the OP with prompt=none–, saving one HTTP request). If it was done that way, then the RP iframe could check that e.source === window.parent I suppose.
> It's probably too late to change this though, and is possibly not a good thing to require as well.
> §8 Security Considerations
> That section doesn't talk about the need for "salting" the session state (more about privacy than security but still), and is silent about the threats that would require the session state to be a crytographic hash: what's the real issue? Examples of scenarios?
> FWIW, my implementation at the OP is open source; feedback is welcome: https://github.com/ozwillo/ozwillo-kernel/blob/f7e03ff628c48931393faf1d35c473a7cb9e685d/oasis-webapp/src/main/resources/oasis-ui/check_session_iframe.html <https://github.com/ozwillo/ozwillo-kernel/blob/f7e03ff628c48931393faf1d35c473a7cb9e685d/oasis-webapp/src/main/resources/oasis-ui/check_session_iframe.html>
> (the sha256.js script used as fallback comes from https://github.com/Caligatio/jsSHA <https://github.com/Caligatio/jsSHA> BTW)
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab