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). If you are interested in working with us to develop authentication and authorization servers, please apply here.
Our ID infrastructure
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. You can read more about our authorization infrastructure at our meetup presentation (in Japanese).
Why switch
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.
Data Migration
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:
- Can we change the identifiers for existing account?
- Can we change the Client ID and OpenID Connect secrets?
- Can we force-reset user passwords?
Let's look at each question in more detail.
Can we change the identifier for existing accounts
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.
Can Client ID and OpenID Connect secret be changed
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.
Can user passwords be force reset
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.
New identity infrastructure architecture
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:
- Ory provides each features as a micro-service. This makes it easy to maintain compatibility when migrating existing data and features.
- We are familiar with the Go language. This makes it easy for us to work on the source code when problems or questions arise.
- We have past experience using and contributing to Ory Hydra. So when we have problems, we can solve them by contributing.
Next I will introduce each system component in our new ID infrastructure.
Ory Kratos
A headless Identity Server that implements user management and authentication. The main features implemented are:
- Login, Logout
- User registration
- Profile Management
- Account Recovery
- Email Verification
- MFA
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
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.
Ory Oathkeeper
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.
My Application
This will be a component that implements miscellaneous missing items, in particular:
- UI for each of the features provided by Kratos.
- additional validation or other processing before POST to Kratos.
- Working with Kratos and Hydra.
- Mapping for account identifier to be compatible with Django issued APIs to federate to other system components.
- The ID infrastructure before the replacement was made in Python (Django), but this time it was implemented in the Go language.
Final Thoughts
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.
