Tailwind is a utility-first CSS framework that one of my colleagues has been advocating internally at Rock Solid Knowledge for some time. After using Bootstrap’s utility classes on my own website, I’m finally sold on the benefits of using utility classes for web design.

Bootstrap’s utility classes are relatively basic, and I soon became jealous of some of the utility classes found in Tailwind, especially the ability to prefix any utility class with a breakpoint name (e.g. md:w-3/4).

Edwards-curve Digital Signing Algorithm (EdDSA) is the new hotness in digital signing algorithms. From what I’ve seen, it’s the current recommendation from the cryptography community and generally preferred over your typical Elliptic Curve Digital Signature Algorithm (ECDSA).

I’ve had a few chances to play with EdDSA as part of my work with FIDO2 and PASETO, so I’m going to solidify that by writing up my high-level understanding of EdDSA, how to use EdDSA in .NET with Bouncy Castle, and how to sign a JWT with EdDSA using ScottBrady.IdentityModel.

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.