[Openid-specs-ab] Feedback on OpenID Connect Session Management

Thomas Broyer t.broyer at gmail.com
Mon Apr 4 15:12:41 UTC 2016

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...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160404/8a1d8544/attachment.html>

More information about the Openid-specs-ab mailing list