Advanced OAuth Security

In this lesson, we'll review the authorization code flow and summarize the roles in OAuth. We'll discuss how a user, device, and application work together to access resources at an API using access tokens. We will also examine how the authorization code flow starts with the user logging in to the application and how the application then exchanges an authorization code for an access token. Understanding these roles and the flow will set the stage for the rest of this course.

Learn about the front channel and back channel in OAuth and how they differ in different environments such as server side apps, single page apps, and mobile apps. Understand the role of the browser, the client, and HTTP library in these processes and how attackers can potentially manipulate data in the front channel.

In this lesson, we'll learn about the different categories of threats that extensions can protect against, including authorization, authentication, and session integrity. We'll also explore how to ensure that access and ID tokens are secure and how to prevent attackers from tricking users into logging in as someone else or using someone else's access token.

This lesson will cover different types of attackers and their capabilities in the context of advanced OAuth security. It will also discuss limitations and assumptions, such as correctly functioning TLS and JWKS URLs, and the assumption that secret keys are kept secret. We'll delve into specific types of attackers, including web attackers, network attackers, and attackers with compromised endpoints, and will discuss how to protect against them in the authorization request process.

In this lesson, we will recap the end to end OAuth flow and show where all the specs and elements in the future lessons relate to the overall flow.  We'll cover topics such as adding integrity to front-channel requests, preventing  authorization code injection, using sender constrained tokens to ensure that only the intended recipient can use an access token, and more. We will also explore different options for client authentication and methods to validate access tokens at the resource server.

In this lesson, we'll learn about authorization code injection attacks, a type of attack that occurs when an attacker injects an authorization code into a browser performing an authorization code exchange. This can have serious consequences, such as a victim being logged into the attacker's account or the attacker being logged into the victim's account. We will also explore measures to protect against these types of attacks, including the use of PKCE to tie a particular request with the resulting authorization code. This attack is relevant to all types of clients, including public and confidential ones.

In this lesson, we'll go through the authorization code flow to understand how an authorization code attack occurs and how PKCE prevents the attack from succeeding. We will see how PKCE associates a secret code with a particular user session, and how it uses this secret code to ensure that the correct authorization code is exchanged for an access token. By the end of the lesson, you will have a deeper understanding of how authorization code attacks work and how to protect against them.

This lesson discusses the history and evolution of PKCE in OAuth 2.0, and how its used evolved over the years from mobile apps to JavaScript apps to now be used by every type of OAuth client.

In this lesson, we'll explore the concept of authorization server mix-up attacks, in which an attacker controls one of the authorization servers that a client may use. We will go through the process step by step, explaining how the attack works and how the attacker can ultimately gain access to an authorization code and exchange it for an access token. We will also discuss the technique to prevent this type of attack.

In this lesson, we'll learn about the Authorization Server Issuer identifier (iss), which helps prevent the "authorization server mixup attack." This mechanism involves the server adding a new parameter, "iss," to the authorization response, which tells the client which authorization server is sending the response.

In this lesson, we will discuss the potential issues that arise when starting an OAuth flow in the front channel, including the risk of the user or other software modifying or intercepting the request, the length and sensitivity of data sent in the front channel, and the lack of guarantee of authenticity for the client making the request.

In this lesson, we'll explore an extension to OAuth called Pushed Authorization Requests (PAR) which makes the authorization process more secure by avoiding the use of the front channel. We will discuss how this extension works and how it can be used with different types of clients, including web servers, mobile apps, and single page apps. We will also delve into the concept of client authentication and how it can be used to add an extra layer of security to the authorization process.

In this lesson, we'll learn about the problems with the simpler "client secret" model of client authentication in OAuth, and explore the more secure forms of client authentication available, including Private Key JWT and Mutual TLS.

In this lesson, we will discuss Mutual TLS as a form of client authentication, in which the client presents its own certificate to the server when establishing a connection. We will also discuss the use of Mutual TLS with reverse proxies and how it can be used to provide identity verification of clients.

In this lesson, we will learn about using a Private Key JWT for client authentication in OAuth and OpenID Connect. We will use a JSON web token (JWT) signed with the client's private key and include certain required claims to authenticate the client to the authorization server. This method is simpler and easier to deploy compared to Mutual TLS.

In this lesson, we will discuss the additional steps that resource servers must take when validating tokens. This includes verifying the validity, integrity, expiration, and revocation status of access tokens. We will also discuss the different ways in which access tokens can be transmitted, as well as the different options for checking a token's revocation status.

In this lesson, we will discuss the concept of Bearer Tokens and how they became the dominant form of access tokens in OAuth. We will also discuss the security risks associated with bearer tokens and the idea of using sender constraining as a solution to improve security.

In this less we'll discuss Mutual TLS as a way to bind access tokens to a client certificate.  We'll cover how Mutual TLS can be deployed with a PKI model or self-signed certificates, and how it can be used to bind access tokens to client certificates in OAuth. This lesson also covers the role of the resource server in recognizing and validating client certificates and access tokens, and the implications of using Mutual TLS with public clients.

This lesson covers DPoP (Demonstrating Proof of Possession), an alternative to Mutual TLS that works at the application layer. It involves the use of JSON Web Tokens to prove possession of a key and establish a link between an access token and the key used to request it. This lesson covers the required and optional claims that must be included in a DPoP proof, as well as how to create and sign the proof. The lesson also discusses the use of nonces to ensure that the client has recently created the proof.

In this lesson, we'll explore how to ensure non-repudiation in the OAuth authorization request. While Pushed Authorization Requests solves the dangers of sending the request details in the front channel, we need something extra to add non-repudiation. We'll introduce the use of JSON Web Tokens to provide a signature for the authorization request to prove that it was actually made by the client.

This lesson focuses on adding non-repudiation to the response the authorization server sends to the client using the "JWT-Secured Authorization Response Mode" (JARM). We'll discuss the use of JARM in the context of the various response modes used in OAuth and OpenID Connect.

In this lesson we'll focus on the JWT Response for OAuth Token Introspection specification, which enables a resource server to request a JWT from the Authorization Server as part of the token introspection process. This JWT contains information about the token being validated, as well as a signature for non-repudiation.

In this lesson, we'll introduce HTTP signatures, a new IETF draft for signing HTTP requests and responses. We'll focus on how HTTP Signatures can be applied in the context of FAPI to add non-repudiation to the client's resource request.

In this lesson we'll apply HTTP Signatures to the resource server's response, so the client can ensure non-repudiation of the responses it gets from the API.