In my previous article I discussed the criticisms surrounding JSON Web Tokens (JWTs) and some of their alternatives. Some of these alternatives had merits, however, many of the implementations that I found neglected to include the payload validation that we are used to in JWT libraries.

I’ve implemented some of these JWT alternatives as a side project, with a focus on including JWT payload validation. Thankfully, the Microsoft.IdentityModel libraries were extensible enough for me to build on top of the existing JWT validators. This means that protecting your APIs with PASETO can look as simple as...

JSON Web Tokens (JWTs) get a lot of hate from the wider crypto community, but what are the alternatives? In this article, I am going to give a high-level overview of some of the recommended alternatives mentioned in Twitter rants and attempt to provide an opinion on whether or not they can replace JWTs.

I in no way want to become the defender of JWTs; this is not the hill I want to die on. However, with the increasing hate on JWTs and what I see as misunderstandings around them and their alternatives, I felt that I had to put something into writing to clear my head.

Azure Key Vault is a great way to store your IdentityServer4 signing keys; it is secure, versioned, and gives you access to robust access control mechanisms. However, I keep seeing many Azure Key Vault integrations that miss many of its features by storing the private key as a secret and then downloading the private key on application startup.

In this article, I’m going to walk through an IdentityServer4 proof of concept in which the private keys never leave Azure Key Vault.

No private keys were downloaded in the making of this article.

Last week Google released an open-source FIDO2 authenticator called OpenSK, implemented in Rust.

OpenSK is not too dissimilar to the Solo Key, but unlike Solo, it is not yet suitable for everyday usage. It is not FIDO certified, and at the time of writing, it uses Rust implementations of the required cryptographic algorithms (e.g. ECDSA), as opposed to using available hardware-accelerated cryptography. For now, OpenSK is for research purposes only.

In this article, I’m going to talk through my creation of a security key using OpenSK (I am a Windows user, and this is all new to me). I’m also going to see how well the current implementation works with a FIDO conformant relying party (registration and authentication) such as FIDO2 for ASP.NET Core.

In that strange period between Christmas and New Years, I finally had a chance to finish off some long-running dev tasks for IdentityManager2. This means that IdentityManager2 now targets ASP.NET Core 3.1, has dropped the beta suffix, and is now contains less legacy code from v1.

It would be wrong not to thank ChaosEngine who’s pull requests and gentle nudging helped make this release happen.

If you have an ASP.NET MVC application in production that uses IdentityServer, you may soon find yourself in its codebase due to the upcoming SameSite cookie changes spearheaded by Google.

While you’re in there messing with the code, why don’t you give your old application a freshen up and update your OpenID Connect usage to take advantage of some of the features of the newer OWIN libraries and the latest security recommendations of authorization code plus PKCE?

I wrote one of these articles last year, talking about what I’d been up to since 2016 and my plans for 2019. I found writing that blog post quite therapeutic, and over the past year, I often caught myself coming back to it (and not just for the pictures).

So, here’s another nostalgic blog post, for a year that felt both too short and too long.

What Happened in 2019

To start, I’ll pat myself on the back. In 2019 I...

Sometimes you need to use an algorithm that your goto libraries do not support. Whether it’s because your platform’s cryptography libraries don’t implement it yet or because a particular client library doesn’t support it, sometimes you need to go off piece.

In this article, we’re going to look at how to do that when using the Microsoft.IdentityModel JWT libraries, using ES256K as our custom signing algorithm. Example code will both generate and verify a JWT signature.

I’ve been using the Java library “Nimbus JOSE + JWT” to create JWTs recently. It has been pretty useful for playing around with uncommon JOSE algorithms such as ES256K and EdDSA. Considering that these are not supported out-of-the-box in .NET yet, being able to use another stack to generate test data has been invaluable.

So, this is one of those blog posts where I write down how to use the library for signature generation and validation for future Scott to reference once he inevitably forgets.

While playing around with IdentityServer4 and mTLS client authentication, I was recommended mkcert for generating trusted development certificates. I found this tool to be super simple to use and it saved me from having to use OpenSSL or the PowerShell replacement for MakeCert (New-SelfSignedCertificate).

So, I thought I would document how to use mkcert on Windows and how to use it for some ASP.NET Core development tasks such as client authentication and pfx generation.