Key takeaways from the OAuth Security Workshop in Trento
Vladimir Dzhuvinov -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:
-
A front-channel mechanism to let an RP poll the IdP for user session changes
via an iframe,
which is more efficient than
prompt=nonerequests. - 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.
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).