Share or discuss this blog post with me on Twitter

IdentityServer really is the swiss army knife of Identity & Access Management (IAM).

Especially for developers. Here, I explain how it was used on a recent project.


I have recently been working for a client on a cloud migration project, where we decided to use IdentityServer for authentication, but not with the typical implementation as an identity provider. As such, I thought it would be useful to blog on our configuration and what IdentityServer has brought to the overall solution.

I hope to expand this to a short series of posts, discussing:

  • a rationale for adopting IdentityServer (this post)
  • how we used it for Single Sign On (SSO)
  • how we used it provide flexibility with a choice of identity providers

Rationale: Why Use IdentityServer

Before elaborating any further on the architecture, I should give some background which will help explain the technical decisions.

Client Scenario

The technology environment is certainly an interesting one, where a mix of .NET, Java and Ruby platforms host the portfolio of applications.

I was part of a team responsible for migrating a suite of .NET applications to the Microsoft Azure cloud platform. While there were a few opportunities for functional improvement, the primary focus of the project was cloud readiness.

The first of those architectural decisions was how to authenticate users when we were migrating away from Integrated Windows Authentication against on-premise Active Directory. Clearly this existing authentication mechanism would not work, and we therefore had to consider identity providers accessible from cloud-hosted applications.

As a consequence of the afore-mentioned diverse technology range comes the diversity of options and choice. In such a situation when you decide to make the move to cloud hosting, architectural decisions invariably take longer; you try consider all options and influences (just as powerful) to ensure you have the right solution for all. The impact of this was that by the time we had started the architecture redesign, no strategic decision had yet been made on a standard identity provider for cloud-hosted applications.

How we used IdentityServer
How we used IdentityServer

As shown here, we had a number of apps in the application suite that were connected to IdentityServer for authentication. IdentityServer integrates and manages any number of external identity providers.

OpenId Connect

While no decision had been made on a single identity provider, there had at least been a decision to (sensibly) standardise on OpenId Connect (OIDC) as the authentication protocol. What this does is it provides you with a standard communication protocol for authentication, meaning as long as the identity provider you are considering are OIDC-compliant, you should be able to swap one out for another (with only minimal configuration change). Which is exactly what we did.

When you have multiple platforms to support, it provides a common protocol not just for technologies but for developers too. We’ve had developers from .NET and Java talking (yeah I know, right?) about the best way to authenticate, fully conversant in OIDC.

(For those not familiar with OIDC, its a great leveller for providing standard authentication. As its an extension of the OAuth2 protocol for access management it works seamlessly.

IdentityServer is an OIDC identity server (and identity provider in one, but we’ll get to that later). Before an identity provider had been selected, we were able to stand up IdentityServer as an authentication server, providing OIDC compliant endpoints (using in-memory users). We then were able to work migration proof of concepts without having committed to a specific identity provider. Invaluable to say the least.

Identity Server And Provider

As IdentityServer is architected in such a way that the identity server and provider components are effectively decoupled, it means you can configure IdentityServer to be an identity server, with zero, one or multiple external identity providers.

In the situation we were in (lack of strategic direction on identity provider) there was a very real possibility that the choice of identity provider may change during the lifetime of the migration project. Using IdentityServer as effectively a proxy authentication server provided a layer of abstraction such that once a decision on the identity provider was made, only this authentication server would need to be reconfigured rather than each of the applications within the suite.

Further, there was always the possibility in such diverse organisations that the strategic direction may be to opt for the provision of multiple identity providers, and let the user determine which they wanted to use for authentication. IdentityServer as an identity server allows for the provision of this provider selection. (While this would mean the user registration and migration processes would be more convoluted, this can be attractive to organisations as it offers better user experience).
Single Sign On

The suite of applications we were responsible for migrating were all inter-related (business-wise). This meant that more often than not, their user base of each application overlapped quite considerably. As already stated, the on-premise versions of these apps used IWA. This meant that while there was no SSO, authentication was invisible to the user. All of which pointed to one thing: we were going to have to provide SSO across all our apps.

Again, enter IdentityServer. As a proxy authentication server, IdentityServer manages all sessions once a user has authenticated and can be configured to manage session lifetimes. With zero additional configuration, providing each application points to the same instance of IdentityServer then SSO just works. Invaluable again.


In the majority of scenarios, IdentityServer is used as an identity provider, typically connected to a custom user database. In our case, we have used IdentityServer to derive the following benefits instead:

  • Provide an industry standard authentication endpoint (using OpenId Connect protocol)
  • Acting as an intermediate identity server, effectively a proxy authentication server, decoupling applications from identity provider(s).
  • Provision of SSO for all applications

Note: Hopefully this blog post demonstrates the power of useful tooling such as IdentityServer. While we used IdentityServer for application decoupling (summary point #2), using IdentityServer as a proxy server can also be useful to decouple your apps from multiple authentication protocols such as OpenId Connect, WS* and SAML.

Share or discuss this blog post with me on Twitter

thunk Software is a trading name of Kavand Ltd, Company Registration No. NI671803

Website template by Stackrole