OAuth articles

Key takeaways from the OAuth Security Workshop in Trento

Posted on 2018-03-19

The OAuth security framework is not static. It keeps evolving, driven by new applications, often in hot fields such as open banking, payments and IoT. The 2018 edition of the OAuth Security Workshop was a three day event where we discussed original use cases brought forward by brave developers and explored new extensions to the framework.

Here are my personal key takeaways.

Logout explained

Much has been said about single sign-on (SSO), but not about logout, especially in the context of OpenID Connect federation. Thanks to the superb work of Brock Allen and Mike Jones, we now have a draft for a comprehensive guide on what logout can mean (semantics) and how to implement it (mechanisms) in various scenarios.

We agreed that the design of logout should always begin by answering these two questions:

  • What are the users’ natural expectations from logout in a given scenario?
  • What security requirements does the application have?

With a clear picture of that we can then go ahead and select appropriate logout triggers and mechanisms.

Possible logout triggers:

  • End-user action, e.g. clicking on sign-out button
  • Application session time-out
  • IdP session time-out
  • Detection of anomalous behaviour or account compromise
  • Account termination

Useful criteria for selecting a logout mechanism:

  • Reliable or best effort? Front-channel logout (via browser redirect or iframe messaging) is relatively easy to implement, but also brittle. If reliability is sought a back-channel method must be considered.
  • Type of logout messaging: request, confirmation, or both?
  • Direction of logout messaging: RP -> IdP and / or IdP -> RP
  • Whether the user is logged out from the application or also from the IdP?
  • Which state is cleared / revoked and which kept: cookies, access tokens, refresh tokens, HTML5 local state, etc.

OpenID Connect already provides four mechanisms related to logout:

AES-SIV mode for JSON Web Encryption (JWE)

JSON Web Tokens (JWT) are widely used in OAuth for self-contained access tokens. They are usually signed, but can also be additionally encrypted, when the token carries claims that must be kept confidential from clients.

There are two standard methods for JWT encryption at present — AES/CBC with HMAC/SHA-256 and AES/GCM.

Both provide strong authenticated encryption. Their security properties rely on the IV being being sufficiently random (AES/CBC), or the nonce non-repeating (AES/GCM). If these conditions aren’t met, the security properties of the encryption crumble, sometimes dramatically. The availability of a secure random generator can indeed be a problem, in constrained IoT devices or in VMs where good entropy for seeding of the generator is difficult to come by.

To mitigate against such risks Neil Madden suggested a new JWE content encryption method based on AES in SIV mode (RFC). For use in JOSE he put together draft-madden-jose-siv-mode-02. The draft also specifies a key wrapping mode based on AES-SIV.

The proposed enc identifiers for JWE:

enc Description
A128SIV AES SIV using CMAC and 256 bit key
A128SIV-HS256 AES SIV using HMAC-SHA-256-128 and 256 bit key
A192SIV-HS384 AES SIV using HMAC-SHA-384-192 and 384 bit key
A256SIV-HS512 AES SIV using HMAC-SHA-512-256 and 512 bit key

Here is link to Neil’s slides on misuse-resistant JOSE encryption with AES-SIV and a detailed paper with references.

New OAuth flows for payment, open banking and IoT

New flows keep popping up and this is a testament to OAuth finding use in new areas.

  • Do you have a scenario where the client is on a different device than the one where the user authenticates and gives consent? This can occur in situations involving POS terminals, smart TVs, or delegating access to a service person. Take a look at Dave Tonge’s presentation of decoupled flows in OAuth 2.0.
  • Torsten Lodderstedt has done a great job in winning over the Berlin Group to consider OAuth in the PSD2 API it is developing. He presented a modified OAuth code flow with Strong Customer Authentication (SCA).
  • Hannes Tschofenig gave a talk on OAuth for IoT, and we discussed a "client token" flow where the ACE / OAuth client uses the resource server to tunnel the token request to the authorisation server.

I had fantastic time in Trento. When we parted on Friday I thanked our wonderful hosts for their hospitality and told them I hoped there would be another OAuth event there!

The next OAuth Security Workshop will take place in Stuttgart, in the week before the IETF 104 meeting in Prague (23 - 29 March 2019).

Key takeaways from the OAuth security workshop in Zürich

Posted on 2017-07-21

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.

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.