Creating a private key for token signing doesn’t need to be a mystery. Recently, I wrote about using OpenSSL to create keys suitable for Elliptical Curve Cryptography (ECC), and in this article, I am going to show you how to do the same for RSA private and public keys, suitable for signature generation with RSASSA-PKCS1-v1_5 and RSASSA-PSS.

Last week, I attended the 5th OAuth Security Workshop (OSW), a workshop where people working with OAuth can meet up and talk about anything related to OAuth security for 3-4 days.

This was my first time attending the OSW, so I thought I would share a few of my highlights and help raise awareness of the event.

By default, IdentityServer4 uses RS256 to sign identity tokens and JWT access tokens; however, it does also support Elliptical Curve Cryptography (ECC). Using Elliptical Curve Digital Signing Algorithms (ECDSA) such as ES256 does have some benefits over RSA, such as shorter signature and smaller keys while providing the same level of security.

In this article, I am going to show you how to use ES256 to sign JWTs in IdentityServer4 and then how to use it alongside RS256 for backward compatibility. I contributed some of the code around ECDSA in IdentityServer4, so I figure it is time to write about it 🙂.

Recently, I have been using OpenSSL to generate private keys and X509 certificates for Elliptical Curve Cryptography (ECC) and then using them in ASP.NET Core for token signing.

In this article, I’m going to show you how to use OpenSSL to generate private and public keys on the curve of your choice.

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.