Identity Server

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

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.

I previously wrote an article on how to use Proof-Key for Code Exchange (PKCE) in a server-side ASP.NET Core application. In the IdentityServer world authorization code with PKCE now replaces OpenID Connect's (OIDC) hybrid flow as our most secure authorization method; however, not all client libraries or even OpenID Providers support PKCE yet. An alternative approach that gives a comparatively high level of assurance is to use the OIDC hybrid flow in combination with encrypted identity tokens via JSON Web Encryption (JWE).

Using the hybrid flow with encrypted identity tokens allows us to validate the authorization response (via identity token validation), ensure that the authorization code was intended for us (via c_hash validation), and prevent PII passing via the browser (thanks to JWE).

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

Swagger is a useful tool for creating basic, on the fly API documentation using a standard JSON format that can be presented using a developer-friendly UI. These UIs typically allow you to start making demo requests via the browser. However, once you start protecting this API using OAuth, how do you keep this Swagger documentation functional?

Swagger integration with OAuth authorization servers is relatively well documented, so in this article, you’re going to see the basics of adding IdentityServer support to an ASP.NET Core API using Swagger and then look at the limitations of this approach and some alternatives that might be worth exploring.

This article will demo both Swashbuckle and NSwag. Feel free to skip to the one that is most relevant to you and then move on to the limitations & improvements section.

Originally published 3 March 2017 on IdentityServer.com

SharePoint is a popular document collaboration platform from Microsoft, capable of running multiple web applications which in turn consist of multiple web sites. SharePoint also comes with of the box support with other Microsoft products such as Office 365 and Active Directory.

But what if you want to use SharePoint with non-Active Directory accounts? Or have SSO across all of your applications, even on mobile devices? Even Azure AD B2C struggles with this, due to its lack of support for SAML 1.1 tokens. This is where traditional identity providers start to struggle and IdentityServer steps in.

IdentityServer4 is the latest iteration of the IdentityServer OSS project, a popular OpenID Connect and OAuth framework for ASP.NET Core. In this article, you are going to see how IdentityServer4 works, and how to create a working implementation, taking you from zero to hero.

IdentityServer 3 vs IdentityServer 4

After IdentityServer4 was initially released, IdentityServer3 was soon switched into maintenance mode, with only security fixes being released. However, in 2019, Microsoft dropped support for the OWIN libraries (Katana 3) that IdentityServer3 relied upon, and as a result, free IdentityServer3 support has ended.

If you are still using IdentityServer3 (or even IdentityServer2), I highly recommend that you consider migrating to IdentityServer4 as soon as possible.

Identity Server 3 is by design an OpenID Connect Provider, however many developers do not have the luxury of using the latest and greatest authentication protocols or have to integrate with existing Identity Providers incompatible with OpenID Connect. To solve this the Identity Server team have enabled the use of various features to enable developers to use the WS-Federation protocol.

OpenID Connect vs WS-Federation

The best way to compare OpenID Connect and WS-Federation is to look at the reason they exist (ie the problem they solved) and the technologies they typically use.

Identity Server 3 comes with out of the box support for ASP.NET Identity in the form of an existing implementation of the Identity Server IUserService interface. This implementation provides the normal Identity Server behaviour using your average ASP.NET Identity implementation as its user store.

This implementation came out of beta for the v2.0.0 release and whilst it's a little rough around the edges, it provides a solid, extensible user service for getting you started.

In this post I’ll cover how to set up the ASP.NET Identity user service, its default behaviour and also how to implement some common extensibility scenarios.

In this post we will create a hybrid flow client and take advantage of some of the features Identity Server and the Microsoft Katana OpenID Connect middleware can offer.

Hybrid Flow

Along with creating an OWIN client, we'll also take the opportunity to play around with the hyrid flow and some basic authorization. This will require some changes to our Identity Server implementation.

Client

To create the necessary hybrid client, add the following client configuration...

Expanding on the Identity Server implementation from my previous post, we will now create some basic MVC clients and start authenticating our client application.

This part of guide will look at manually integrating an ASP.NET MVC application with Identity Server, so that we can see some of the features and processes of OpenID Connect 1.0 and Identity Server 3 in action. Part 3 of this guide will cover the use of the OpenID Connect katana middleware to automatically configure an application to use Identity Server.

Welcome to the first part of my Identity Server 3 Implementation Guide. To start with we'll walk through a standalone implementation of Identity Server 3 using the implicit flow, ready for a basic MVC application to authenticate against it. This initial post will be similar to the starter documentation with the bonus of using a standalone implementation and taking the time to talk through some of the concepts in more detail. We'll start with the implicit flow as this is the simplest to demonstrate, and the default for IdentityServer, using future posts to explain the hybrid flow and authorizing access to an API.

Thinktecture’s Identity Server v3 is a .NET implementation of the OpenID Connect 1.0 and OAuth 2.0 specifications. The culmination of Dominick Baier and Brock Allen’s experience with security and token services, IdentityServer was written from scratch to meet OpenID Connect specifications, acting as your very own identity provider (aka an OpenID Connect Provider).