⬅ Back

General pointers on getting your IdentityServer 4 project production ready

Published: 08 Oct 2016
Reading time: 4 min

Disclaimer: As of the writing this post, IdentityServer 4 is not production ready, it is in release candidate, close to RTM. And as such IdentityServer 4 is not officially production ready.

Deploying your first IdentityServer 4 web application into production use may be something that you may be looking at. If you are just starting out with IdentityServer 4 and OpenIDConnect/OAuth it might be a little bit overwhelming. There is a lot to learn and grasp but if you follow these general pointers, you and your new found relationship with IdentityServer 4 will go very smoothly. Even if you are only doing a proof of concept or protoype using IdentityServer 4, you might want to know about these things going forward when assessing what sort of effort needs to be undertaken to get your PoC into something that is a fully fledged project.

The Signing Certificate

Regardless of the platform you choose to deploy your identity provider web app to, you need to make sure that your signing certificate is stored in a safe location and is retrieved in a safe manner. If you are using Azure, you can use Azure Key Vault (similarly for Amazon, you can use AWS Certificate Manager).

Your deployment artifact should NOT include the signing certificate as part of the package. Rather your application should rather pull the signing certificate down from a secret vault as mentioned before.

There will come a time where you will need to perform a certificate rollover. This happens when your current signing certificate is due to expire, or for any other arbitrary reasons, you may want to switch the certificates without affecting your service levels. In IdentityServer 4 you effectively have to choose a primary credential for token signing and verification, however you can have an additional credential for verification as well. Basically, if you need to perform a rollover you just need to add a new certificate as a primary credential and demote the old signing credential. Consider the common scenario below:

Certificate A is valid from January till the end of June, and certificate B is valid from the beginning of June onwards. Certificate B is added as a primary signing credential in the beginning of June, however all tokens issued prior to that by A can still be verified by your identity server since certificate A has been relegated to “verification only�? status. Do Note: A, and B’s keys still appear in the discovery document however new tokens issued will be signed by B (from the beginning of tune) and if there exists any tokens that were signed by A, we can still verify them. When the last token signed by A has expired you can drop certificate A completely.

Persistent Configuration & User Accounts

Persisting the configuration of the identity server application is something that you may want to do if you want to configure your deployment of IdentityServer 4 without having to redeploy the changes via code, or you may want to persist the configuration because you want to persist the state of the configuration between load balanced instances of IdentityServer 4. If you want to do this, you must make sure that you implement these as being backed by some form of persistent storage:


For the purposes of this post, it doesn’t entirely matter what database technology you use, just make sure that you are aware of the sort of migration plan that you might need to employ to make this work. The popular choices for doing this persistence is MongoDB and MS SQL. IdentityServer 4 has an EntityFrameworkCore implementation that hooks right into the AspNet Core services container nicely. You can find out more about it here.

As for user accounts, for some applications you can get away with federating identity from other providers, however if you need application specific user info that cannot be provided by other providers, then persisting users is also something that should be highly considered. If you do such a thing you will also probably need to implement IProfileService to grab data from your persisted data store. Please to practice the appropriate means to securely storing salted passwords.

Login Page & UI

Like any other AspNet Core MVC Razor page, the login page for your IdentityServer 4 project can be fully customizable within the laws of what the world-wide web allows. While this is not provided out of the box, you may want to add extra controllers for user registration, it is as simple as adding another controller/view with the dependency required for it to create users. Add styling and extra form validation to these views to improve the user experience of those using your identity server to sign in to.

Extending the IdentityServer 4 Services

You should not be scared to extend the out of the box services to fit your needs. You may notice that many of the identityserver 4 configuration interfaces are defined such that only data retrieval is possible. You may want to extend these interfaces to include the other CRUD operations. There is no configuration management portal analogue to IdentityServer 4 that is IdentityServer3.Admin, but this does not stop you from building one yourself if you require that level of configuration manipulability.

While the documentation for IdentityServer 4 is still young, it doesn’t stop you from rummaging through its source to look for other points of extensibility.

In Ending

Your identity provider still needs to go through the churn of what normal projects go through. The code should be built through an automated build system, Its unit tests should be run on every commit (and ideally before committing) and integration tests should be run against deployments of your project running in segregated environments. Stress/Load testing should also be done so that you can determine the applications capacity. It should go through code reviews. You should also use a reliable logger that works with the AspNet Core logging framework, but be CAREFUL to not log sensitive data. It also may not hurt to look at some rate limiting middleware so that you can further protect your identityserver 4 endpoints. While the pointers in this post are quite broad, I hope that it might have helped you in prioritising what is important in getting your project production ready.