[OpenID] Some thoughts on Open ID Connect Session

[boris8479 at gmail.com]

Hi Community,

My name is Boris Georgiev and I am in charge for Application Security in a large financial institution. I do appreciate bringing up the standard Open ID Connect. I am excited after so many years, finally there is a standard. However, when facing up with Open ID Connect Session spec, I started to experience some disappointments.

Section 3 says: “In Open ID Connect, the session at the RP typically starts when the RP validates the End-User's ID Token”. In my mind, as I am trying to protect everything, I am about to receive the session together with the ID token, i.e. via the token API. However, reading further, the spec states that the variable session_state is returned in “the authentication response” which was changed few specifications back from “the authorization response”. The reference to 3.1.1.5 core shows example with the authorization code, and there is no example, showing the code and the session_state together. I was thinking initially that it is my confusion only, however I showed it to other engineers, native English speakers and they were confused too. I do believe this needs to be explained better, which session is which. So far I did not like the fact, that the session state is returned in a redirect via GET request, which we all know its vulnerabilities.

Further, section 4 explains that this is all about session state change notification, so the RP can refresh the ID token, avoiding the network traffic. So far so good. Finally, section 4.2 explains that the session actually is hashed and re-calculated at the OP frame. I think finally, the session is safe. However, to my disbelief, the spec explains that OP frame “may” use a cookie which is not http only, so it can be accessed by a JavaScript. Here I start wondering how people with security regulations similar to mine pass audit.

If the session is passed to the OP frame in some other secure way and if it is not used for any other purpose but for the session change notification, this will solve the problem. However the spec does not list it anywhere as a security concern, neither recommends secure ways. Moreover, I saw open source implementations out there, where the same cookie is driving the Single-Sign-On at the Authorization Server. This means, once the value of this cookie is obtained, it can be used to invoke the authorization API, bypass authentication and if implicit grant is requested, the attacker can get access tokens. The last safeguard is the callback URL, which can be easily bypassed by overwriting the local hosts file. Sounds like a complex and almost impossible, however in the financial industry the security is attempted to be penetrated by the brightest minds across the globe where patience and persistence can be well awarded. I need just one case like that to end my career. Therefore I do need to think about closing all the gaps and I still cannot find piece, thinking what else can be out there.

I do believe the above security concerns need to be listed in the spec. And I do believe this non http cookie idea needs to be listed in the security concerns, instead of being recommended.

If you need my opinion how it can be improved:

There is already a mechanism to protect token exchange. This is via the authorization code and token API. I thing, passing it from there will eliminate the need of encryption. Then, the session_state can be embedded in the script of the RP frame and comparison/calculation logic to be embedded in the OP frame (not via a cookie). Encryption is great, but one of the goals of OAuth is for authentication/authorization not to be done too often. The solution is acceptable for desktops, powered by the power grid, but for a thin device, one cannot do often encryption operations and expect a great battery life. I do not know if anyone ever considered that and was there any reason not to be pursued.

Regards,
Boris Georgiev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20160331/6c21212a/attachment.html>