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.
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:
- A front-channel mechanism to let an RP poll the IdP for user session changes
via an iframe,
which is more efficient than
- A front-channel mechanism for an RP to notify the IdP of user logout and optionally also let the user log out of the IdP
- A front-channel mechanism to let an IdP notify RPs of user logout, by rendering an iframe to an RP endpoint
- A back-channel mechanism to let an IdP notify RPs of user logout, by posting a logout token to an RP endpoint
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.
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:
|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|
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).
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
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 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.
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.