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 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?

Or, it’s not IdentityServer, it’s you.

A common issue with when integrating with an OpenID Provider, such as IdentityServer4, is getting caught in an infinite redirect loop. Typically, this redirect loop will eventually crash your browser tab, or the browser itself.

In Chrome, you’d get the ERR_TOO_MANY_REDIRECTS error message. Or, if you’re issuing cookies to track nonce and states values with each redirect and not cleaning up after yourself (I’m looking at you OWIN/Katana), then you’ll probably get an a 400 Bad Request, with a message of something like “The size of the request headers is too long”.

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.

Back in September 2017, I spoke at the .NET South West user group, and I’ve just realized that this is the first time one of my talks has made it online. I thought it was worthwhile sharing, especially since it’s a talk I probably won’t be doing again.

It’s always odd seeing yourself on camera, but I’m fairly happy with how well this talk went, especially considering that this talk took place on one of the few nights in September that I was actually at home/in the country (sorry again, Rachel).