Does OneLogin Work in China? Identity Data Residency & Login Reachability
OneLogin (by One Identity) runs no mainland-China region — it hosts identity data only in its US or EU regions, so for Chinese users it's a cross-border transfer of personal information under PIPL, and the sign-in flow is served offshore, making login availability a compliance-and-operations risk. A compliance-first look at the doors.
Does OneLogin work in China?
No — not as it stands. OneLogin runs no mainland-China region: it hosts your users' identities in its US or EU region and serves the sign-in flow from offshore, so for Chinese users it is a cross-border transfer of personal information first, and a login-availability risk second.
OneLogin's own SDK sets the data region to "Optional: us or eu. Defaults to us," and its documentation notes the login address is "the same address you would use to login to OneLogin" — a <subdomain>.onelogin.com host. So the directory of names, emails, credentials, MFA factors and authentication logs for your Chinese users lives in the US or EU — a cross-border transfer PIPL governs (Articles 38–43), with an in-mainland storage duty for CIIOs and large-volume handlers (Article 40; Cybersecurity Law Article 39 (formerly Article 37)) — and if that offshore sign-in is slow or blocked, users simply cannot log in. OneLogin itself needs no ICP; that duty falls on the app it protects. The table below pairs OneLogin's own wording with the rule each point triggers.
This is a risk map, not a verdict — what applies turns on your entity, your data volumes and who your users are. Our China team can map your exposure with you →
Compliance snapshot
- ! Your Chinese users' identities live in OneLogin's US or EU region — offshore
- ! Serving China is a cross-border transfer of personal information — PIPL applies
- ✕ OneLogin runs no mainland-China region to switch your tenant to
- ! Sign-in is served offshore — if it's slow or blocked, users can't authenticate
- ✓ OneLogin itself needs no ICP — but the app it protects does
What OneLogin's own documentation says about China
| Fact | Primary source |
|---|---|
OneLogin hosts identity data only in a US or EU region — there is no mainland-China option. OneLogin's own SDK exposes a single data-region setting — "Optional: us or eu. Defaults to us" — so unless the EU region is specifically arranged, a tenant comes up in the United States. Either way your Chinese users' identities are stored outside the mainland: a cross-border transfer of personal information under PIPL (notice, separate consent and a transfer mechanism, Articles 38–43). | OneLogin Ruby SDK README (github.com/onelogin/onelogin-ruby-sdk), retrieved 2026-10-07; PIPL Articles 38–43 |
The sign-in flow itself is served from OneLogin's offshore hosts. OneLogin documents that its API and login share one address — "The OneLogin API uses your subdomain as the API Domain. This is the same address you would use to login to OneLogin" — and its OpenID Connect authorization, token and userinfo endpoints resolve to https://<subdomain>.onelogin.com/oidc/2/…. If that offshore endpoint is slow or unreachable from inside the mainland, your users cannot finish authenticating and are locked out of the protected app — an availability risk, not merely a slow paint. | OneLogin developer docs — API overview and OpenID Connect provider configuration (developers.onelogin.com), retrieved 2026-10-07 |
| An identity provider holds exactly the data PIPL treats as most sensitive. OneLogin's directory keeps user names, email addresses, login credentials and MFA factors, together with the authentication and event logs behind every sign-in — all personal information of your Chinese users. Held in OneLogin's US or EU region, that is a cross-border transfer under PIPL; and for a critical information infrastructure operator or a large-volume handler, personal information collected in China must be stored in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)) — which an offshore region cannot do. | OneLogin product documentation (users, directories, MFA, events), retrieved 2026-10-07; PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37) |
| OneLogin carries no ICP filing — the app it protects does. An IdP is a backend identity service, not the public website a mainland visitor browses, so the ICP filing (ICP 备案, under State Council Order No. 292 and MIIT Order No. 33) attaches to the public-facing application and its in-country hosting resource, not to OneLogin. Adopting OneLogin neither provides nor removes that obligation; what it adds is the identity-data residency question and the login dependency above. | 21YunBox compliance analysis; State Council Order No. 292; MIIT Order No. 33 |
Sources verified by the 21YunBox compliance team on 2026-10-07.
For a mainland-China audience, the deciding question about OneLogin is not how quickly its login screen paints — it is where your users’ identities are allowed to live, and whether the sign-in flow can be reached at all. OneLogin answers the first in its own documentation: it provisions accounts only in a US or EU region, with no presence inside mainland China. So a China-facing OneLogin deployment keeps the directory of names, emails, credentials, MFA factors and authentication logs offshore — a cross-border transfer of personal information China’s law governs — and serves the sign-in flow from offshore too, where a slow or blocked connection does not merely annoy users, it locks them out of the application entirely. OneLogin itself needs no ICP filing; that duty lands on the app it protects. The residency and the availability are the exposure.
OneLogin in China at a glance
| What decides it | In OneLogin's own terms |
|---|---|
| Where it runs | OneLogin provisions accounts in a US or EU region — its SDK region setting is “Optional: us or eu. Defaults to us.” No region is inside mainland China. |
| Where identities live | User directories, names, emails, credentials, MFA factors and authentication logs are stored in that US or EU region — outside the mainland. |
| Where sign-in is served | The login and OpenID Connect flow resolves to https://<subdomain>.onelogin.com — “the same address you would use to login to OneLogin” — served offshore. |
| Serving the public (ICP) | OneLogin is a backend identity service, not the public site, so it carries no ICP filing of its own; the ICP obligation falls on the app it protects. |
| The exposure | For Chinese users, offshore identity storage is a cross-border transfer PIPL governs; an offshore sign-in that is slow or blocked locks users out — availability, not just speed. |
US or EU only — so your users’ identities sit offshore
OneLogin provisions every account in one of two places. Its own SDK exposes a single region setting — “Optional: us or eu. Defaults to us” — so unless the EU region is specifically arranged, a tenant comes up in the United States. There is no third choice inside mainland China. Whichever region holds your tenant, the identity records an IdP exists to keep — user directories, names and email addresses, password and MFA credentials, and the authentication and event logs behind every login — are stored outside the mainland.
For your Chinese users that storage is a cross-border transfer of personal information under the Personal Information Protection Law. The handler — you, not OneLogin — has to give notice, obtain separate consent, and clear one transfer mechanism: a CAC security assessment, the CAC standard contract, or certification (PIPL Articles 38–43). If you are a critical information infrastructure operator or a large-volume handler, personal information collected in China has to be stored in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)) — a residency duty neither a US nor an EU region can satisfy. Picking the EU region may help a GDPR story; it moves the data between two offshore locations, not into China.
The login flow is offshore too — and that turns reachability into an availability risk
With most offshore tools, a slow connection from inside the mainland is a nuisance. With an identity provider it is a door that will not open. OneLogin serves the sign-in itself from its own hosts: its documentation states “The OneLogin API uses your subdomain as the API Domain. This is the same address you would use to login to OneLogin,” and its OpenID Connect authorization, token and userinfo endpoints all resolve to https://<subdomain>.onelogin.com/oidc/2/…. Every authentication round-trip therefore leaves the mainland and comes back.
So if that offshore endpoint is slow, intermittent or blocked for your mainland users, they do not merely wait — they cannot complete sign-in, and they are shut out of whatever application sits behind OneLogin. That is an availability question about your whole app, not a speed question about one screen, and it is why an identity provider is the dependency worth testing first for China.
The ICP line isn’t on OneLogin — it’s on the app it guards
It is tempting to ask whether OneLogin itself needs an ICP filing. It does not, and that is the honest answer: OneLogin is a backend identity service, not the public-facing website a mainland visitor browses, so the ICP 备案 regime under State Council Order No. 292 and MIIT Order No. 33 attaches to the application and the mainland hosting resource it runs on — not to the IdP. Adopting OneLogin neither creates nor clears that obligation. What OneLogin changes is the other two exposures: where your users’ identities are stored, and whether they can reach the thing that signs them in. Keep those two straight and the compliance picture stops being about login speed and starts being about data residency and availability.
This is a risk map, not a verdict: whether a cross-border transfer mechanism, in-country storage, or both apply to you depends on your entity, how much personal data you hold, and who your users are — worth settling with counsel before you build.
Where 21YunBox fits — a compliant overlay, not a migration
You keep running OneLogin exactly as it is. We add what an offshore identity provider cannot give you on its own: compliant, ICP-filed delivery from inside the mainland, set in front of the application OneLogin protects — no rebuild, no second codebase, and no move off OneLogin. Our China team maps your PIPL cross-border and data-residency obligations against your entity and data volumes, works through the login-availability risk for your mainland users, and stands up the in-country delivery a lawful China presence needs, while your identity stack stays where it already runs.
Related reading:
Frequently Asked Questions
Can we just pick OneLogin's EU region to stay compliant in China?
No — neither region is in China. OneLogin provisions accounts in the US by default, with the EU as the only alternative, and both sit outside the mainland. Choosing the EU can help a GDPR story, but for your Chinese users it is still a cross-border transfer of personal information under PIPL, and it does nothing for the mainland data-residency duty that applies to a CIIO or large-volume handler. The region switch moves your identity data between two offshore locations, not into China.
If OneLogin's login screen loads, does that mean it 'works' in China?
Treat reachability and compliance as two separate questions. Because the login and OpenID Connect flow is served from OneLogin's offshore hosts, an unstable or blocked connection from inside the mainland means users cannot authenticate and are shut out of the whole app — so availability is a real operational risk, not just slower paints. But even if sign-in loads instantly, storing your Chinese users' identities offshore is still a cross-border transfer PIPL governs. Loading fast does not make it compliant.
Can 21YunBox help make our OneLogin setup work in China?
Yes. Our China team can map your exposure — the PIPL cross-border and data-residency questions around the identity data OneLogin holds, and the login-availability risk for your mainland users — and stand up the ICP-filed, in-country delivery a compliant China presence requires in front of the app OneLogin protects, with no rebuild and no move off OneLogin. Get in touch to work through your specific case.
