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.
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.Read more
With the rising popularity of patterns such as microservices, it is becoming more and more common that the API that your client application is calling, isn’t the API that is going to be performing the requested functionality. Instead, you could be calling an API gateway.
OAuth is all about delegation. It allows a client application to ask 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 itself then needs to interact with other protected resources? How do we keep this request acting on the user’s behalf? How do we do this securely without getting the user involved again?Read more
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.Read more
OAuth is not authentication. It’s an authorization protocol, or, better yet, a delegation protocol. It’s for this reason that authentication 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.Read more
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.Read more
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.
We’re going to use the OAuth terminology of...Read more
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.Read more