How to Add OneID Login to a Website or App

How OneID login works

OneID is Uzbekistan's single identification system: one account for government services and the private services connected to it. For you, it is a way to get a verified identity without checking passports yourself.

The flow resembles the OAuth 2.0 Authorization Code grant:

1. The user clicks "Sign in with OneID" on your site.
2. You redirect them to OneID with your client ID, a return URL, the requested data (scope) and a state parameter.
3. The user signs in to OneID (password, e-signature or another available method) and approves data sharing.
4. OneID sends them back to your redirect_uri with a one-time code.
5. Your server exchanges the code for an access token using the client secret.
6. With the token, the server requests user data and creates or finds the account.

Browser -> your site -> OneID (sign-in) -> redirect_uri?code=...&state=...
your server -> OneID: code + client_secret -> access_token
your server -> OneID: access_token -> user data

Take exact endpoints, parameter names and grant_type values from the documentation the operator provides after onboarding: they may differ from standard OAuth.

What you need to connect

• A legal entity or government body — individuals usually do not get access.
• An application to the OneID operator describing your service, the purpose of processing and the fields you need.
• A domain and return URL registered for your client.
• Compliance with the personal data law: a privacy policy, user consent, and storage of Uzbek citizens' data on servers inside the country.
• A test environment, if the operator provides one — debug there, not on real accounts.

Request only the fields you actually need. A wider scope means more questions during approval and more responsibility for storage.

What data you receive

The set depends on the approved access and the user type. Typically:

Use the PINFL or the persistent OneID identifier as the linking key, not phone or email: contacts change.

Integration security

• Client secret on the server only. Never ship it in a mobile app or frontend. The mobile app opens sign-in in the system browser, and your backend performs the code exchange.
• Validate state. Generate a random value, store it in the session and compare it on return — this protects against CSRF.
• Strict redirect_uri. HTTPS only, and only pre-registered addresses.
• The code is single-use and short-lived. Exchange it immediately and never log it.
• Do not keep the access token longer than needed. Once you have the data, issue your own session.
• Encryption and access control. Store passport data encrypted, with role-based access and an audit log.
• Logout. Decide whether signing out of your service ends the OneID session, and tell users.

Fallback sign-in options

OneID can be unavailable, and some users have no account. So:

• keep phone sign-in with an SMS code or email for basic features;
• let users link OneID to an existing account to avoid duplicates;
• gate only identity-critical features behind OneID and leave the rest open;
• on OneID errors, show a clear message and a retry button, not a blank page.

Common mistakes

• Exchanging the code in the browser or app with an embedded secret.
• Creating a new account on every sign-in because accounts are linked by phone.
• Requesting every available field "just in case".
• No monitoring, so users are the first to report a broken integration.