A signed JSON Web Token (JWT) is one of the most useful and common constructs you’ll see floating around modern security systems. These tokens give us a simple, secure structure in which to transfer data and verify that it has not been tampered with. However, what about when we need to send sensitive data within a JWT?

To solve this issue, we have JSON Web Encryption (JWE), enabling us to encrypt a token so that only the intended recipient can read it.

In this article, we’re going to look at how we can protect sensitive data within our JWTs in .NET Core, using JWEs and the various token libraries available to us.

JWE Format

We’re going to use JWE Compact Serialization (as opposed to JWE JSON Serialization), which looks something like the following...

Recently, there’s been a bit of a palaver around a draft specification proposed to the OAuth Working Group and its recommendation of abandoning the implicit flow in browser-based applications, e.g. Single Page Applications (SPAs), in favor of the authorization code flow with Proof-Key for Code Exchange (PKCE).

This article is going to look at how to update the Angular application found in my previous article “SPA Authentication using OpenID Connect, Angular CLI and oidc-client”, to start using the authorization code flow and PKCE.

Software tokens, such as those you use in software token apps such as Google Authenticator and Authy, have been getting a bit of flack recently thanks to the growing adoption of FIDO2 and WebAuthn. Software tokens (aka soft tokens) still have their benefits and are easily one of the most widely adopted second factors used alongside passwords; however, I think a lot of us are using them for the wrong reasons. Not only are soft tokens phishable, but in the event of a breach, soft tokens won’t save you.

In this article, I’m going to look how a typical TOTP software token implementation works, and then pick apart their advantages and disadvantages.

The past few years since joining Rock Solid Knowledge have been a bit of a blur. I’ve gone from living in a small flat in Cornwall with no central heating, sat all year in a small office of 3, to being married, living in a city, and becoming sick of flying.

I know I’ve accomplished a lot these past few years, but I still seem to feel like I’m not moving fast enough or that someone will eventually discover me for the fraud that I am.

So, to combat this feeling, and since my wife keeps telling me that I should share what I do more often, I’m going to publicly take stock of the past couple of years and think about what I want from 2019. In true social media fashion, I’m going to only discuss the positives, but obviously there were some lows; however, those are private.

Hopefully, this will be useful for me to review again in 2020.

What’s Happened since 2016

In the mad rush since 2016, I have...

Over the years I’ve experienced many opinions about the default IdentityServer4 storage libraries; however, no matter your views on entity framework, clustered indexes, and varchar lengths, if you have concerns with the defaults then my advice is always the same: If you have database expertise in-house, use it and create your own storage layer.

Creating your own IdentityServer4 persistence store is very simple. There are only a handful of interfaces to implement, each with just a few read and write methods. They are not full repository layers, nor do they dictate database type or structure.

So, let’s take a look and see what’s involved with implementing our own IdentityServer4 storage library...

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).