High Security OAuth

Since its publication in RFC 6749 and RFC 6750, OAuth 2.0 has gotten massive traction in the market. It became the standard for API protection and its usage has been expanded to use-cases and environments than originally considered and anticipated including the financial industry, health care, e-commerce and e-government. It also became the foundation for OpenID Connect – which is now the most popular authentication protocol for modern applications.

    These environments need more security features than originally specified in OAuth. That’s the reason both the IETF (BCPs) and the OpenID Foundation (FAPI) started working on a number of documents which update the original specs and threat models and give more prescriptive guidance. The discussion during creation of those documents led to the conclusion that OAuth itself needs updates to provide a better security baseline for the things to come.

    The workshop has four parts:

    Part 1
    First, we look at the so-called “best current practices” (or BCP) documents that cover security patterns and anti-patters as well as common attacks and implementation flaws and how to fix them. This includes general implementation guidance, as well as very specific guidance for web applications, SPAs and native apps.

    All these BCPs combined form the foundation for the upcoming revision to OAuth called OAuth 2.1

    Part 2
    Next, we will look at currently released add-on specifications that help improve the security of today’s OAuth architectures. These include:

    • hardening the front-channel with PKCE and signed authorization requests
    • hardening the back-channel with asymmetric key based client authentication and mutual TLS
    • hardening API calls with proof-of-possession access tokens

    Part 3
    In part three we look at future specs that take OAuth to the next level and are in line with the grand vision currently code-named “OAuth 3.0”. This includes:

    • A replacement for the scope parameter using rich authorization request
    • Eliminating all classes of attacks against the browser front-channel using pushed authorization requests

    Part 4
    In the last part of the workshop, we will have a look at FAPI 2.0 which defines a basic and advanced high-security profile for OAuth 2.0 and 2.1 (independent of financial scenarios) and how to apply it to the technologies you learned throughout the day.

    Dominick Baier
    Duende Software

    Dominick spent most of his professional career implementing security systems for his customers and reading protocol specifications. This resulted in a number of popular open-source projects like IdentityServer and IdentityModel. Since 2020 he runs Duende Software Inc together with his longtime friend and colleague Brock Allen. Duende provides a sustainable home for the IdentityServer project and is the one-stop-shop for all things OpenID Connect and OAuth for .NET-based companies.

    Brock Allen
    Application Security Architect

    Brock Allen is a consultant specializing in .NET, web development, and web-based security. He also is an instructor for the training company DevelopMentor, associate consultant for Thinktecture, a contributor to the Thinktecture IdentityModel and IdentityServer open source projects and a contributor to the ASP.NET platform.

    Programutvikling uses cookies to see how you use our website. We also have embeds from YouTube and Vimeo. How do you feel about that?