OAuth

Client authentication allows an OAuth client application to prove its identity to an OAuth authorization server. The simplest way to do this is using a client secret, but client authentication is so much more than just client secrets.

In this article, you’ll learn about the various client authentication methods available to you in OAuth, both symmetric and asymmetric, and why you might want to move away from client secrets.

JSON Web Tokens (JWTs) give you a standardized security token format; however, they can often be abused due to gotchas in the core standards and subpar library design. Learn how to use JWTs securely with my latest course on Pluralsight: JWT Fundamentals.

JSON Web Token (JWT) is a standardized security token format that allows you to securely transmit data between parties as a self-contained JSON object. You’ll often see JWTs criticized for their use of cryptographic agility; however, due to their popularity and flexibility, it’s more than likely that you’ll need to use them at some point.

This course will teach you how to use JWTs securely, adhering to modern best practices while defending against the permissive nature of the core JOSE standards, regardless of your programming language or framework.

Open Banking is the UK’s implementation of PSD2, a directive that aims to open banks up for collaboration and encourage competition. To achieve this, Open Banking uses OAuth 2, bringing its own set of extensions to the protocol and its own set of acronyms.

In this article, you will build upon your existing OAuth knowledge to learn about Open Banking’s architecture, its new acronyms, and what implementation is the best fit for you.

Implementing step-up authentication doesn’t need to involve your applications orchestrating calls to multiple complex APIs. Instead, by leveraging the features already available to you in open standards, you can build low-friction, stateless step-up authentication for all applications using the protocol libraries they are most likely already using.

In this article, you’re going to learn what step-up authentication is and how you can use step-up authentication in a stateless way within your APIs using OAuth and client applications using OpenID Connect. I’ll even throw in a bonus example that uses SAML 2.0.

You’ll also see an emerging approach where the API (the protected resource) itself can trigger step-up authentication.

Recently, I have received questions asking if Proof-Key for Code Exchange (PKCE) is a replacement for OAuth client authentication and, if so, why do my articles still use a client secret for server-side applications?

Is PKCE a replacement for client authentication? The short answer is: no.

Should you still use client authentication where possible? Yes.

In the same way that OAuth is not authentication, it also does not tell us what the user is allowed to do or represent that the user can access a protected resource (an API).

Understanding what OAuth is not is just as important as knowing what it is, in order to use it effectively. In this article, I’m going to discuss how OAuth does not include user authorization and why user authorization rules should not live within your OAuth authorization server.

TL;DR: OAuth is not suitable for user authorization. The fact that you have an access token that allows you to act on the user’s behalf does not mean that the user can perform an action.

Last week, I attended the 5th OAuth Security Workshop (OSW), a workshop where people working with OAuth can meet up and talk about anything related to OAuth security for 3-4 days.

This was my first time attending the OSW, so I thought I would share a few of my highlights and help raise awareness of the event.

Recently, Okta released an article titled “Nobody Cares About OAuth or OpenID Connect” that authoritatively stated that “Developers don’t care about OAuth or OpenID Connect”. I strongly disagree.

I recommend you give the article a read before reading my rebuttal below (although you might want to skip to “Why Nobody Cares About OAuth and OpenID Connect” and onwards).

Their key takeaways are:

• The security community needs to keep developers safe
• Developers using OAuth and OpenID Connect client libraries is similar to them rolling their own crypto
• Client libraries should handle all of the authentication and authorization for developers, not just OAuth and OpenID Connect

Confused how to properly authenticate access an API when using a browser-based application? Then use the below cheat sheet to choose the right approach for your needs.

The Scenario

I have an application running within the context of the browser (e.g. a React or Angular Single Page Application (SPA)) that wants to access an API on behalf of a user. This authenticated API call will be made directly from the user’s browser, and only our application should be able to call it on behalf of our authenticated user (i.e. we’re not vulnerable to Cross-Site Request Forgery (CSRF/XSRF).

Passwords suck. We all complain about them and constantly look for alternatives or add multiple factors to secure our user authentication. So why do many of us still use passwords to authenticate our OAuth clients? After all, a client ID and client secret is just a username and password with a different name.

One of the easiest ways to remove the use of shared secrets for client authentication is to replace them with public-key cryptography by using JWT Bearer Token for Client Authentication defined in RFC 7523 and again detailed in the core OpenID Connect specification as the private_key_jwt client authentication method.

This flow makes use of signed JSON Web Tokens (JWTs) to simplify public-key cryptography, allowing us to use well known and established libraries to simplify our implementation.

With the rising popularity of patterns such as microservices, it is becoming more and more common that the API your client application is calling isn’t the API that will be handling the request. Instead, you could be calling an API gateway, or an API will end up calling yet another API.

OAuth is all about delegation. It allows a client application to ask the resource owner (a user) for permission to access a protected resource (an HTTP API) on their behalf. It is a delegation protocol.

So, what happens when a client application communicates with a protected resource that needs to interact with other protected resources? How do you keep this request acting on the user’s behalf? How do you handle this API-to-API communication securely without getting the user involved again?

I’m really excited to announce the release of my latest Pluralsight course: “Getting Started with OAuth 2.0”.

In this course, we take a look at the OAuth 2 authorization framework and some of the work that’s been happening that makes OAuth and its extensions the gold standard for API security.

This course is going to be entirely programming free and is suitable for software developers of any language or stack. That being said, if you’re looking to get started with IdentityServer4, I highly recommend this course as your first step.

OAuth is not authentication. It’s an authorization protocol, or, better yet, a delegation protocol. It’s for this reason that identity protocols such as OpenID Connect exist and legacy protocols such as SAML use extension grants to link authentication and delegation.

There are articles on this subject already, but I still regularly see some confusion as to the reasons why on the internet and with new clients. So in this article, I’m going to discuss the key reasons why OAuth on its own does not provide client applications (relying parties) with user authentication.

OAuth & Browserless Devices

One of the last few legitimate usages of the Resource Owner Password Credentials (ROPC) grant type is for browserless devices, for example, a smart TV and other such Internet of Things (IoT) devices. I’ve talked before about why ROPC should not be used in any new application and that it was only designed to quickly tokenize legacy applications (and that’s legacy back in 2012), but let’s take a quick look at why it should not be used for IoT devices:

OAuth’s Resource Owner Password Credentials (ROPC) grant type, aka the password grant, was included in the original OAuth 2.0 specification as a temporary measure back in 2012. It was designed as a quick way of migrating old applications from legacy authentication mechanisms, such as HTTP Basic Authentication or credential sharing, and onto an OAuth tokenized architecture.

However, even though it was created as a temporary measure in 2012, and despite the community’s best efforts, the odd architect or two will still see the grant type’s username & password fields and say, “Aha! That’s the grant type for me!”. ROPC is especially common in mobile apps, where it has the most significant security issues.

In this article, you will learn why the password grant type is such a bad idea for modern systems, why it is so tempting when first learning OAuth & OpenID Connect, and how there are no remaining use cases for ROPC.

Knowing why we don’t use past methodologies can be just as useful as knowing why we use current ones. In this article, we are going to look at past methods for delegating access to an API (the problem that OAuth is the current solution for) and why we shouldn’t use them anymore. Examples in this article are based on systems I’ve seen in the wild or discussed on StackOverflow.

Scenario

For a user to delegate access (or authorize, give permission) to a mail service to send emails on the user’s behalf. Only send permission must be allowed.

Recently as part of my audition process to become a Pluralsight author I created a 10 minute video on ‘Consuming External OAuth Services using IdentityModel’. I’m pretty pleased with how it turned out, and luckily so were Pluralsight, so I thought I would share it for all to see.

In the video, I talk about why OAuth exists, what a basic OAuth request looks like and how we can use the IdentityModel library to help us simplify the process in .NET.

The only thing I didn't have time to fit in was a comparison between making an OAuth request yourself vs. IdentityModel. I've added this code below as I think it is an interesting comparison.