Employment work
Tsuruha identity platform
Architecture and implementation of a custom Keycloak-based identity provider for authentication, authorization, and identity management.
Context
For a major Japanese drugstore chain, Brain Station 23 built a custom identity provider on Keycloak. I led the architecture and implementation. The platform supports authentication, authorization, and identity management for more than 10 million accounts. This figure describes identities supported by the platform, not monthly active users or concurrent traffic.
Problem
A large organization needs a coherent way to authenticate users, decide what they can do, and operate identity as a product capability rather than a one-off login screen.
My role
I led both the architecture and the implementation: how the identity provider is shaped, how authorization is expressed, and how the surrounding services are built. The implementation stack includes Python, FastAPI, PostgreSQL, Redis, Celery, AWS, and Keycloak.
Constraints
Identity systems are sensitive by default. This page stays at the level already stated on my resume: the kind of platform, the account scale, my leadership of architecture and implementation, and the technologies involved.
Reasoning
I start from the authorization boundary. Authentication gets a user in; authorization decides what that user may do across products. A custom IdP is justified when the organization’s identity rules do not fit a generic hosted login, and when the team can operate Keycloak and the services around it. I would not recommend that path for a small product that only needs a single sign-on button.
Outcome
The delivered result is an identity platform in production for those accounts, with authentication, authorization, and identity management as explicit capabilities.
Reflection
The hard part is not installing Keycloak. It is deciding which identity decisions live in the IdP, which live in the product, and how those stay consistent as more applications depend on them.