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

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