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 via both a standard JSON format that can then be presented via a UI. These UI’s typically allow you to start making demo requests via the browser. However, once we start protecting our API using OAuth, how do we keep this Swagger documentation functional?

Swagger integration with OAuth authorization servers is relatively well documented, so in this article, we’re going to look at 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.

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 it’s lack of support for SAML 1.1 tokens. This is where traditional identity providers start to struggle and IdentityServer steps in.

Identity Server 4 is the newest iteration of IdentityServer, the popular OpenID Connect and OAuth Framework for .NET, updated and redesigned for ASP.NET Core and .NET Core. In this article we are take a quick look at why IdentityServer 4 exists, and then dive right in and create ourselves a working implementation from zero to hero.

• IdentityServer 3 vs IdentityServer 4
• Implementing IdentityServer4 on ASP.NET Core and .NET Core
• OAuth Functionality
• User Interface
• OpenID Connect
• Entity Framework Core
• ASP.NET Core Identity

IdentityServer 3 vs IdentityServer 4

A popular phrase going at the moment is 'conceptually compatible' but this rings true for Identity Server 4. The concepts are the same, it is still an OpenID Connect provider built to spec, however most of its internals and extensibility points have changed. When we integrate a client application with IdentityServer, we are not integrating to an implementation. Instead we are integrating using the OpenID Connect or OAuth specifications. This means...

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.

Example Implementation

To keep things simple we’ll use some of the in-memory implementations from my Identity Server implementation guide, but instead of using the hard-coded InMemoryUsers, we'll be using the AspNetIdentityUserService...

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.

Form Post Client

By using the form post response mode authorization, authorization response parameters are encoded as HTML form values and transmitted via HTTP POST to the requesting client, with result parameters returning with a body using the application/x-www-form-urlencoded format. You can find further examples and security considerations for the form post response mode in the OAuth 2.0 Form Post Response Mode Specification. The form post response mode mitigates some of the security implications of encoding response values in the query string and in the fragment value.

Installation

All we need for this is a basic ASP.NET project using the MVC template. Do make sure you don't add any of the authentication templates when you create the project.

Required packages...

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.

Installation

To start off we'll need an empty ASP.NET application, no templates needed. Make sure you enable SSL through the project properties, and set this HTTPS URL as the project default.

The following two NuGet packages are necessary for installing Identity Server 3...

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

From the horse’s mouth:

IdentityServer is a framework and a hostable component that allows implementing single sign-on and access control for modern web applications and APIs using protocols like OpenID Connect and OAuth2. It supports a wide range of clients like mobile, web, SPAs and desktop applications and is extensible to allow integration in new and existing architectures. – github.com/IdentityServer/IdentityServer3

So what does that mean?