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.
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.
TL;DR: OAuth != authentication.If you need to know the users identity then use OpenID Connect, don’t hack it yourself.
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:
Why the Resource Owner Password Credentials Grant Type is not Authentication nor Suitable for Modern Applications29 August 2017 OAuth Last Updated: 17 September 2018
When you ask a consultant if you should use the Resource Owner Password Credentials (ROPC) grant type, the standard response is: “It depends”. While this is true, I’m going to take a stand and say no. Unfortunately, many people see the username & password fields and say “Aha! That’s the one for me!”. I then have to spend way too much of my time trying to convince them it’s a bad idea after they’ve already spent a lot of time implementing it.
So, let’s take a look at the ROPC grant type, why it’s so tempting, and what we can do to convince other developers and stakeholders that it is a bad idea.
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.
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.