We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

How not to use OAuth

Formal Metadata

Title
How not to use OAuth
Subtitle
New security recommendations for OAuth
Title of Series
Number of Parts
94
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
I am coauthoring the new security recommendations RFC for OAuth 2.0 in the IETF OAuth Working Group. In this talk, I will walk you through the MUSTs, MUST NOTs, and SHOULDs of the new recommendations. OAuth is the most important framework for federated authorization on the web. It also serves as the foundation for federated authentication using OpenID Connect. While RFC6749 and RFC6819 give advice on securing OAuth deployments, many subtle and not-so-subtle ways to shoot yourself in the foot remain. One reason for this situation is that OAuth today is used in much more dynamic setups than originally anticipated. Another challenge is that OAuth today is used in high-stakes environments like financial APIs and strong identity proving. To address these challenges, the IETF OAuth working group is working towards a new Security Best Current Practice (BCP) RFC that aims to weed out insecure implementation patterns based on lessons learned in practice and from formal security analyses of OAuth and OpenID Connect. The BCP gives concrete advice to defend against attacks discovered recently (like the AS mix-up attack) and discourages the use of less-secure grant types such as the Implicit Grant. This talk will outline the challenges faced by OAuth in dynamic and high-stakes environments and go into the details of the MUSTs, MUST NOTs, and SHOULDs in the new Security BCP.