Toward a Global Identity Platform
Introduction
Hi! I’m gia, from the Mercari ID Platform team. Our team is in charge of authentication and authorization across Mercari group services.
This article is part of the blog series Behind the Scenes of Developing Mercari’s First Global App, “Mercari Global App”.
In this article, I’d like to share how we extended Mercari’s Identity Platform to support global accounts, contributing to the company’s ongoing global expansion efforts.
The global expansion initiative
Starting point
Mercari’s cross-border business began in 2019 through collaborations with international partners. In this model, Mercari items are listed on partner platforms, allowing overseas users to purchase them. However, there is no direct interaction between these users and Mercari’s services. Instead, transactions are facilitated by proxy buyers, who purchase items from the Mercari C2C marketplace and then ship them to the end users. While this approach enables international access, it also limits the overall user experience — for instance, users are unable to use coupons, participate in promotional campaigns, or access certain platform features.
Until 2024, Mercari’s Identity Platform exclusively supported Japanese users. The platform functions as an identity provider (IDaaS) for all Mercari Group services, offering robust authentication, authorization, and access control capabilities. It supports a variety of authentication methods, including passwords, SMS one-time passwords (OTP), social network (SNS) logins, and Passkeys. Through this system, users can create a Mercari account and use single sign-on (SSO) to access Mercari’s services seamlessly. Our clients range from web-based applications to mobile apps, though the IdP frontend was standardized to provide a consistent web-based experience across platforms.
Over the years, our account system has evolved alongside Mercari’s growth. However, a significant portion of it still resides within a legacy PHP monolith. Although we have made substantial progress toward migrating to a microservices architecture, the transition is still ongoing. Decoupling the account system is a crucial step in strengthening and modernizing our Identity Platform to better support Mercari’s global ambitions.
Initial requirements
Our team learned about Mercari’s global expansion initiative at the beginning of 2024. The first milestone focused on enabling Taiwanese users to create accounts and purchase items directly from the Mercari C2C web platform. At this initial stage, users would have access only to marketplace features, while other offerings—such as Fintech services—were intentionally excluded.
Because this effort represents the acquisition phase, we prioritized making account creation as simple as possible. To achieve this, we initially adopted a straightforward email-and-password registration flow. Given that users interact with Mercari exclusively through the web interface, verifying their email addresses was essential to ensure that important notifications could be reliably delivered.
Additionally, supporting multiple languages was a key requirement. A significant amount of content—including the Terms of Service, Privacy Policy, and other user-facing materials—needed to be properly localized to provide a smooth and trustworthy experience for our new users.
Global Identity Platform Challenges
When a business expands into new countries/regions, it inevitably encounters unique challenges depending on the region, business model, and underlying systems. In our case, several key challenges stood out during the early phase of global expansion:
1. Legacy System Dependency
As described earlier, our account system still relies heavily on legacy components. Migrating existing Japanese accounts is not a simple task, and introducing global accounts presented an additional layer of complexity. Since global accounts were built from scratch, we wanted to avoid incorporating them into the old system. However, many existing services still depend on the legacy account infrastructure, making it a significant challenge to decouple the systems while ensuring overall service continuity.
2. Access Control
Not all Mercari features are available to global users, which means feature access must be carefully controlled based on a user’s region. Additionally, the initial global rollout uses only email-and-password authentication, which doesn’t have a high assurance level. Features that require stronger assurance must therefore be protected by mechanisms based on Authentication Assurance Level (AAL) and Identity Assurance Level (IAL).
3. Internationalization and Localization
Expanding from a Japan-only platform to a multilingual system is far from trivial. Much of our existing UI and business logic was tightly coupled with Japanese-specific design and assumptions. Designing an extensible approach for adding new languages—both for the frontend and backend—proved to be a significant technical challenge.
4. Different Signup Requirements per Region
Each country/region introduces its own regulatory and compliance requirements. For example, some regions mandate age verification during account creation, while others require distinct KYC (Know Your Customer) procedures. Designing a flexible yet maintainable system to accommodate these diverse regional requirements—without introducing excessive complexity—was another critical challenge.
Global account registration
Legacy system decoupling
To support global accounts, we developed a new registration flow encompassing both backend and frontend systems. In this new flow, account data is no longer stored in the legacy system; instead, it resides in a dedicated microservice. However, because many existing services still reference the legacy database, we needed to maintain backward compatibility. To achieve this, we implemented a reconciler that synchronizes data between the new and legacy databases, ensuring consistency across systems.
Each user now has a single account that can be used globally. To support this, we introduced a country_region_code attribute to the account model, enabling regional differentiation and handling for various use cases.
Account readiness check
Typically, account registration involves multiple steps spanning different business domains. For example, email-and-password registration falls under the Identity team’s ownership, while KYC (Know Your Customer) processes are managed by the KYC team. In the legacy system, where a single database and API server handled all processes, temporary data could be stored in intermediary tables before being finalized.
In contrast, the new microservices architecture separates responsibilities by domain, with each service managing its own database. This made the use of temporary tables impractical. To address this, we built an Account Signup Orchestrator—a service responsible for validating account readiness and coordinating the various signup steps across domains. It also enables a more resilient user experience: if a user drops out partway through the registration process, they can resume from where they left off without starting over.
Customizable registration flow
As mentioned earlier, account signup requirements can vary significantly by region. If the registration flow logic were to be managed entirely on the frontend, maintaining and updating these conditions would quickly become complex and error-prone. To address this, we decided to centralize condition management on the server side while keeping the frontend as an orchestrator.
In this approach, the frontend orchestrator retrieves signup instructions from the server, dynamically rendering the appropriate user interface based on those instructions. It continues this process iteratively—fetching new instructions and updating the UI—until it receives a signal indicating that the flow has been completed.
This architecture not only simplifies how we handle region-specific signup conditions but also allows us to manage different authentication requirements, such as the elevation flow (described in the next section), in a consistent and extensible way.
Global account login
Ideally, we aim to provide a single, unified login page that serves both Japanese and international users. However, the available authentication methods must be tailored by region. For instance, LINE login should only appear in regions where the service is supported. Due to time constraints during the initial rollout, this unification was not implemented, and we currently maintain separate login pages for non-Japanese users. Nevertheless, we are actively working toward consolidating these experiences to deliver a more seamless and consistent login flow for all users.
Region based access control
To manage feature availability across different regions, we introduced a region-based access control mechanism, implemented at two layers: the authorization server and the resource servers.
Authorization server
At the authorization server level, access control is enforced during the token issuance process. We extended the OAuth 2.0/OIDC client settings to include a list of supported countries/regions.
| ClientID | Supported countries/regions |
|---|---|
| ClientID_A | JP |
| ClientID_B | HK, TW |
When a client requests an access token, the authorization server verifies that the account’s country_region_code is included in the client’s supported region list before issuing the token. This ensures that only clients operating in approved regions can obtain valid credentials.
Resource server
Once an access token is issued, clients can interact with various resource server APIs. However, not all endpoints are globally available. Each resource server owner can define which regions are supported for specific endpoints through configuration. During token verification, the resource server checks whether the country_region_code associated with the access token is permitted for the requested endpoint. If the region is not allowed, access to that endpoint is denied.
Together, these two layers of validation provide a robust and flexible framework for controlling feature access by region while maintaining consistency across Mercari’s distributed system architecture.
Internationalization and localization
As you can imagine, supporting global accounts required us to handle a large amount of content that needed both internationalization (i18n) and localization (l10n). While internationalization focuses on presenting the same content in multiple languages, localization ensures that content is appropriately adapted for each specific region or culture.
To support our global rollout, we added new versions of key materials such as the Terms of Service, Privacy Policy, and email templates, along with translations for a wide range of user-facing messages across our systems.
We leveraged the ui_locales parameter defined in the OpenID Connect specification to manage language selection dynamically. Users can also specify their preferred language, allowing us to deliver a more personalized and accessible experience across regions.
Global phone number support and elevation flow
To enable users to access features that require multi-factor authentication (MFA)—such as coupons and promotional campaigns—we needed to introduce global phone number support. Unlike the Japanese C2C marketplace, where phone numbers are required at signup, we chose not to request them for global accounts to avoid forcing users to complete two separate OTP verifications (one for email and one for phone number) during registration.
Instead, phone number registration is initiated dynamically through an AAL/IAL-based access control mechanism. Each API endpoint is pre-configured with a minimum required level of assurance. When a user attempts to access a protected endpoint, the system verifies whether their account and current authentication session meet the required assurance level. If they do not, the request is rejected, and the client triggers a flow prompting the user to provide additional information or complete further authentication steps. We refer to this as the elevation flow.
The elevation flow supports multiple verification types—not only phone number verification but also additional methods such as Passkey registration and authentication challenges. It was designed based on the principles of the Step-Up Authentication Challenge Protocol, leveraging the acr_values and claims parameters to determine which verification method should be initiated. These requirements can be specified by the client or enforced directly by the authorization server through configurable policies.
This approach gives us a flexible and secure way to progressively elevate user assurance levels, improving both security and user experience without overcomplicating the initial signup process.
Global mobile application support
After successfully rolling out our Marketplace web services to additional regions, we began developing a global mobile application to deliver a more seamless and localized experience for our international users. Similar to the Japanese app, the IDP flows are handled within in-app browsers. To enable session sharing between the in-app browser and external browsers—allowing users to seamlessly single sign-on (SSO) into web services—we utilized ASWebAuthenticationSession on iOS and Chrome Custom Tabs on Android.
The global app supports multiple regions and includes pre-login features. Upon the first launch, users are asked to select their country/region. This introduced a unique challenge: the country/region selected in the app might differ from the country_region_code associated with the user’s account after login. For new registrations, we can safely skip the country/region selection step during signup. However, in the case of sign-ins (or when users are already logged in through web services), the system must detect and handle mismatches between the selected country/region and the account’s country_region_code. To resolve this, we implemented an error-handling flow that returns a response to the application side, prompting a country/region change process within the app.
As part of this initiative, we also took the opportunity to standardize our logout process to align with the RP-Initiated Logout specification, ensuring consistency across platforms and compliance with OpenID Connect standards.
Future works
As we continue expanding Mercari’s global presence, several key initiatives are underway to support our next phase of growth:
1. Automating Country/Region Rollouts
To accelerate our global expansion, we aim to automate the process of launching Mercari services in new countries/regions. While AI can play a valuable role in streamlining these rollouts, our immediate focus is on simplifying and standardizing the underlying processes to ensure scalability and reliability.
2. Centralized Account Management Portal
We have begun an initiative to develop a unified user account management portal. Currently, each Mercari service maintains its own account settings page, which can lead to inconsistency and confusion. By consolidating these into a single, centralized portal, we aim to provide a more cohesive and user-friendly experience across all services.
3. Expanding Passwordless Authentication
Our passwordless authentication initiative has been active in Japan for some time, and we’ve learned many valuable lessons from that experience. We plan to extend this capability to global accounts, offering a faster, more secure, and frictionless sign-in experience for international users.
4. Regulatory Compliance and Regional Expansion
When expanding our business to other countries/regions, ensuring compliance with regional regulations (e.g. GDPR, CCPA, COPPA) is essential. Strengthening our privacy and data protection frameworks will be a key step in achieving this.
5. Advancing Global eKYC and Digital Identity
Finally, we are exploring enhancements to our global electronic Know Your Customer (eKYC) procedures. Leveraging digital wallets and verifiable credentials presents an exciting opportunity to streamline identity verification, similar to how we have successfully integrated Japan’s My Number system.
These efforts reflect our ongoing commitment to building a secure, scalable, and globally accessible identity platform that empowers users around the world to engage with Mercari seamlessly.
Finally
On November 13, 2025, Mercari Group’s tech conference, Mercari GEARS 2025, will take place. I’ll be presenting a poster session on Mercari’s Global Identity Platform, where I’ll share more insights and discuss our ongoing challenges and future plans.
If you have any questions or would like to chat after reading this article, please feel free to stop by and talk with me at the event. There will also be many other exciting sessions covering a wide range of topics—be sure to check them out!
Register here 👉 https://gears.mercari.com/
Tomorrow’s article is by @Karthi. Please continue enjoying the Behind the Scenes of Developing Mercari’s First Global App, “Mercari Global App”.
