How and why TIER IV replaced IdentityServer with Ory
Use free open source Ory as alternative to IdentityServer to build infrastructure with modern, cloud-native, and scalable services.

Ory Guest
Use free open source Ory as alternative to IdentityServer to build infrastructure with modern, cloud-native, and scalable services.

Ory Guest
Hello 👋, I am Sawada, a developer of authentication and authorization servers at TIER IV. In this article, I describe how we replaced our in-house IdentityServer infrastructure at TIER IV with (Ory Kratos, Ory Hydra, and Ory Oathkeeper).
TIER IV has many infrastructure services including a fleet management system, a remote monitoring and control system, and a map editor for autonomous driving. Our identity infrastructure is a small but extremely important component since outages of this service will massively impact our availability. This ID infrastructure is a very compact service that provides account management and ID federation. Authorization is done by a separate service.
Our existing ID infrastructure was not particularly old but had some problems. The OpenID Provider library that we used was no longer maintained, requiring us to fork and patch it ourselves. It had memory leaks and was sometimes getting stuck on requests.
While we had these issues under control, we knew that this architecture would reach scalability limits in the future. Anticipating more traffic and higher levels of reliability, we decided to replace it while the number of users is still small and the data is easier to migrate.
For our new system we want to use managed services like Cognito (we use AWS) but only those that don't charge by users count and are based on open-source. We see implementing from scratch only as the last resort. However, migration the existing data severely limited our options. Specifically, we evaluated the following requirements:
Let's look at each question in more detail.
No. Our microservice architecture persists IDs across various services. It would be difficult to find them all and replace them consistently. Since our Django-based system uses auto-incrementing IDs, we were unable to find a service or open source alternative that could import existing account IDs without modification. We worked around this problem with a mechanism that converts issued IDs before adding them to our system.

Yes. Of course, it would have been nice to migrate the old secrets, but most of the users inside and outside the company were beyond the scope of change here.
No. Not only is this bad user experience, but there was a time in the past when we did not verify that the email addresses are valid. So some of our users might not be able to reset their password. We needed a new system to import PBKDF2-hashed passwords and this disqualified AWS Cognito.
We decided to go with the Ory Stack. Ory Kratos as the Identity Server, Ory Hydra as the OpenID Provider, and Ory Oathkeeper as the Identity & Access Proxy. We also implemented service specific logic and federated Kratos, Hydra, and the UI. Keycloak is a more well-known open source identity infrastructure but we chose Ory's services for the following reasons:

Next I will introduce each system component in our new ID infrastructure.
A headless Identity Server that implements user management and authentication. The main features implemented are:
I already wrote about Ory Kratos for the Qiita Advent Calendar 2021.
We had to make a decision wether to use Ory Kratos or not. It depended on whether it could import our existing passwords hashed by PBKDF2. I created an issue, implemented the import, and finally opened a PR and merged. Now Kratos can import passwords hashed by PBKDF2 and upgrade to them to the primary algorithm (Argon2id or bcrypt). Ory Kratos can create identities using the Admin API.
Ory Hydra is an OpenID Connect Certified OpenID Provider. Normally, Ory Hydra generates the Client ID and Secret automatically. But we can import it if we set Client ID and Secret.
This is an identity-aware proxy that provides access control. It propagates user session information to upstream and validates the scope of the access token. If you want to authorize users, you need to use Ory Keto or a project like Open Policy Agent, but we did not use them this time. We also use Ory Oathkeeper to protect the administrative APIs of Kratos and Hydra. Eventually we would like to authorize users, but we have issued an OAuth 2.0 client for the admin API, and just scope authorization. This is enough for us at the moment.
This will be a component that implements miscellaneous missing items, in particular:
We were able to complete the migration of our identity infrastructure to the Ory stack without any problems in three months. A major success factor was that we minimized the migration scope by removing unnecessary features prior to the migration. We collaborated with the business and legal departments to identify them and notified our users about the sunset schedule. While that took a lot of time, the process was smooth. If we would have to do the migation today, it would required a considerable larger amount of time. Another big success factor was that the Ory stack is Open Source. It allows us to add additional features to our identity infrastructure from now on.
