Key takeaways from the OAuth security workshop in Zürich
The 2017 OAuth Security Workshop at the ETH in Zürich was packed with useful talks. Here are the key takeaways.
Best practices for native OAuth apps
Check out the best practices for OAuth apps, presented by John Bradley and William Denniss. The slides are based on the formal BCP document that is being edited the OAuth WG.
Are you developing native apps that require OAuth? The AppAuth libraries developed by the great community at OpenID support Android, iOS as well as NativeJS.
John also updated us on the upcoming SafariViewController changes in iOS 11 and that we'll have to rely on SFAuthenticationSession instead, in order to achieve SSO between apps and the system browser.
OAuth for JavaScript apps
Jacob Ideskog presented a nice framework for simplifying OAuth and OpenID Connect integration in JavaScript apps. The app can obtain the tokens it needs by simply posting a message to an iframe loaded from the authorisation server / IdP.
OAuth is becoming the new "password"
The proliferation of OAuth 2.0 applications, even to areas like finance, means we must take greater care to secure tokens, through their entire lifecycle -- how they are obtained, relayed and consumed. Deployments are also turning more dynamic. This means the basic OAuth 2.0 framework (RFC 6749) published in 2012 is no longer adequate. Security must be enhanced, across the board.
Check out the slides by Torsten Lodderstedt and John Bradley on the proposed Mutual TLS, resource indicators and token binding specs to prevent token phishing. The measures in resource indicators are already supported in the Connect2id server, and we're going to have support for Mutual TLS in one of the next releases.
The ability to bind data structures to the TLS (HTTPS) channel will be a big deal once it gets fully supported by browsers. Cookies are the "low hanging fruit", and will be followed by access, refresh and ID tokens. Mike Jones was so kind to give us an update on that.
How to harden the code flow in OAuth by Nat Sakimura, by adding integrity protection to the authorisation request (by signing it) as well as the authorisation response (by using an ID token with state hash
s_hashas detached signature).Users also have an important role in security, which is shaped by UX and developer enrollment. Naveen Agarwal shared insightful lessons from Google on that.
We need more science, i.e. formal analysis, in protocol design
The design of security protocols, like TLS, has been treated like art for a long time. But that's not good enough. We need more science, meaning formal analysis, to be confident that the desired security properties of the protocols we craft are actually met, and critical bits don't get overlooked.
David Basin from the ETH demonstrated the power of formal analysis tools, used for example, to uncover a terrible security omission in the ISO/IEC 9798 protocol.
Cas Cremers made a reassuring presentation that formal analysis has been taken up by the TLS 1.3 working group, to good effect. The whole Internet security relies on TLS, so we must seek to have total confidence in the protocol.
Daniel Fett, Ralf Kuesters, and Guido Schmitz from Uni Stuttgart presented their in-depth analysis of OpenID Connect and the conclusion that within their formal model, the protocol is secure. This is great news!
Crypto: Validate all EC keys that you deal with
Antonio Sanso presented the invalid curve attack and how it can lead to JWE ECDH exploits. The lesson: Always validate the curves of EC keys you're dealing with. In the Nimbus JOSE+JWT library we now perform these validations at EC JWK construction time, even before any crypto operations are attempted with them.