[Openid-specs-ab] Feedback on OpenID Connect Session Management
t.broyer at gmail.com
Fri Apr 29 08:53:31 UTC 2016
It's been more than 3 weeks now (nearly 4 weeks if we ignore the upcoming
week-end), and zero feedback, could someone please chime in?
On Mon, Apr 4, 2016 at 5:12 PM 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
> 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
> 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:
> (the sha256.js script used as fallback comes from
> https://github.com/Caligatio/jsSHA BTW)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab