UAE Pass Integration Guide for Web & Mobile Apps (2026)

What is UAE Pass and why integrate it?

UAE Pass is the UAE’s national digital identity: a mobile app that lets citizens, residents and visitors sign in to government and private services, sign documents digitally and share verified documents. A UAE Pass integration gives your users password-less login with verified identity data, which cuts onboarding friction and KYC effort.

The official UAE Pass developer documentation describes it as part of the Smart Government National Plan, managed by Digital Dubai, TDRA (the Telecommunications and Digital Government Regulatory Authority) and the Abu Dhabi Digital Authority. It offers three capability groups to service providers:

• Authentication - for government entities and private organizations
• Digital Signature and eSeal - for government entities and private organizations
• Data and Document Sharing - for private organizations (government entities integrate document sharing through GSB)

For a UAE-facing app, “Sign in with UAE Pass” is quickly becoming what users expect, especially in fintech, real estate, healthcare, education and anything that touches government services. At NomadX, our AI-native software studio in Dubai builds web and mobile apps where UAE Pass login is often part of the first release. This guide is what we wish we had the first time: what the process looks like, what the integration actually involves, and where teams get stuck.

One rule for the whole article: UAE Pass changes its docs and processes over time. Everything technical here is taken from the official docs as of October 2026. Where something is unclear or likely to change, we say so. Always check the current UAE Pass documentation before you build.

How does the UAE Pass onboarding process work?

UAE Pass onboarding runs in four phases: initiation (request access, submit questionnaires, workflow diagrams and wireframes), development (staging credentials and integration), assessment (recorded test scenarios reviewed by the onboarding team) and go-live (production credentials and a production check). You cannot skip straight to production credentials.

Here is what each phase involves, according to the official onboarding pages.

Initiation phase

1. You request integration through the UAE Pass developer portal, stating whether you are a government or private entity.
2. Private entities are asked for a valid UAE trade license. The onboarding team that guides you depends on the emirate you are registered in.
3. You receive a welcome email with reference documentation.
4. You submit questionnaires for each feature you plan to integrate (authentication, digital signature, eSeal, hash signing, data sharing).
5. You submit a workflow diagram of your UAE Pass user journey, based on the standard use cases in the docs.
6. You submit UI mockups (wireframes) of those journeys.
7. The onboarding team evaluates and approves the use case. Use cases that deviate from the standard guidelines need management approval, which the docs warn can extend the timeline.

Development phase

The onboarding team shares staging credentials, and starts the agreement process: a Service Provider Agreement (SPA) for private entities or an MOU for government entities. You build against staging and tell the UAE Pass team when you are ready for assessment, using the assessment checklist for your feature.

Assessment phase

The onboarding team runs an assessment session against the checklist. If they find issues, you fix them and request another round. You also share video recordings of every tested scenario, which go to management for approval. Private entities complete SPA signing before moving on.

Go-live phase

You submit the go-live form for your features, receive production credentials, implement against production, confirm the go-live date, and the onboarding team runs a production assessment. After that, you get service desk access for post-launch incidents.

The practical lesson: UAE Pass integration timelines are driven by approvals and assessments as much as by engineering. Pick a standard use case, prepare the diagrams and wireframes properly, and build the full journey (not just the happy path) before you book the assessment.

How does UAE Pass login work technically?

UAE Pass authentication uses the standard OAuth 2.0 authorization code flow: redirect the user to the authorize endpoint, receive a code at your redirect URI, exchange it server-side for an access token with HTTP Basic client credentials, then call the userinfo endpoint to get the user’s profile attributes.

Staging vs production endpoints

The docs list these endpoints:

For staging you need a test user created in the staging UAE Pass app, which is a separate app from the production one. The docs provide the staging apps and instructions for creating and upgrading staging accounts.

Step 1: Authorization request

Redirect the browser to the authorize endpoint with these parameters:

• response_type=code
• client_id - issued by the UAE Pass team
• redirect_uri - must match what is registered with UAE Pass
• state - a random value to protect against CSRF; validate it on return
• scope - the standard profile scope is urn:uae:digitalid:profile:general; visitor integrations add profileType and unifiedId scopes
• acr_values - for standard web login the docs use urn:safelayer:tws:policies:authentication:level:low
• ui_locales - en or ar to render the login page in English or Arabic

The user enters their identifier, confirms a push notification in the UAE Pass app, and is redirected back to your redirect_uri with code and state.

Step 2: Token exchange

Your backend POSTs to the token endpoint with grant_type=authorization_code, the same redirect_uri and the code. Authentication is HTTP Basic with your client ID and secret, and the docs specify Content-Type: multipart/form-data. The response contains a Bearer access_token with an expires_in value (3600 seconds in the documented example). The docs mention that an ID token is returned if the openid scope was requested; check with the onboarding team whether that applies to your configuration.

Two details that trip people up: the docs say the authorization code should be used within 10 seconds, and the redirect_uri must be identical in the authorize and token calls.

Step 3: User info

Call the userinfo endpoint with Authorization: Bearer {access_token}. For a verified user you get attributes such as uuid, userType (SOP level), fullnameEN, fullnameAR, firstnameEN, lastnameEN, nationalityEN, gender, mobile, email, idn (Emirates ID number) and idType. Which attributes you receive depends on the user’s SOP level and on what is approved for your application. Visitors do not have idn; they get profileType and unifiedId instead.

Step 4: Logout

When the user logs out of your app, the docs say you should also log them out of UAE Pass by redirecting to the logout endpoint with a redirect_uri. The common integration issues page notes that the newer system only accepts the state parameter for extra data, so encode anything else into state.

Keep the whole token exchange on the server. The client secret never belongs in a browser bundle or a mobile binary. If you are building the backend from scratch, our backend and API engineering work follows the same rule for every OAuth provider.

How does UAE Pass work in mobile apps?

For mobile, UAE Pass documents an app-to-app flow: your app opens the authorization URL in a WebView with a mobile acr value, catches the UAE Pass deep link, rewrites its success and failure URLs to your own URI scheme, launches the UAE Pass app, and resumes the flow when the user comes back.

The documented steps, in short:

1. Check if the UAE Pass app is installed. On Android the docs give the staging package ID ae.uaepass.mainapp.stg; on iOS the schemes are uaepass:// (production) and uaepassstg:// (staging).
2. If installed, load the authorization URL with acr_values=urn:digitalid:authentication:flow:mobileondevice in an embedded WebView.
3. Watch the WebView for the UAE Pass deep link containing successURL and failureURL.
4. Save both URLs, then rewrite them to point at your own scheme (for example yourapp://resume_authn?url=...), carrying the original URL as a parameter.
5. Open the rewritten deep link to launch the UAE Pass app. The user confirms there.
6. Handle the callback to your scheme, then load the saved success URL in the same WebView so the authorization server completes the flow.
7. Catch the redirect to your redirect_uri, take the code, and do the token and userinfo calls on your backend, exactly as on web.
8. If the app is not installed, use the standard level:low acr value; the user enters their identifier and confirms on another device with UAE Pass.

The docs are explicit about one thing: use your own app scheme, not the demo app’s scheme, in both staging and production, or the callback can land in another provider’s app. UAE Pass also publishes iOS and Android SDK guides and sample apps.

For cross-platform frameworks, this flow maps cleanly to a WebView plus deep link handling. In Flutter that is a WebView plugin plus app links; in React Native it is a WebView component plus the Linking API. The fiddly parts are the same in both: URL encoding of nested callback URLs, iOS universal links vs custom schemes, and Android intent filters. Test every path on real devices with the staging app, including “user cancels” and “app not installed”. Our mobile app development team treats these as acceptance tests, not afterthoughts.

What are UAE Pass SOP1, SOP2 and SOP3 accounts?

UAE Pass SOP levels are account assurance levels. SOP1 is a basic unverified account, SOP2 is a verified advanced account, and SOP3 is a verified qualified account verified with biometrics. Your app reads the level from the userType attribute and decides which services each level can access.

Two design rules from the official implementation guidelines matter here. First, the SOP level must appear in your use case diagram, so decide early which levels each feature allows. Second, keep the experience consistent with your local login: if basic unverified users can use basic services through your own login, the guidelines say the same users should be allowed in through UAE Pass.

How do UAE Pass digital signatures and eSeal work?

UAE Pass digital signature lets a logged-in user sign PDF documents with their UAE Pass identity. SOP2 users sign at advanced level and SOP3 users at qualified level; SOP1 users cannot sign. The docs make UAE Pass authentication a mandatory prerequisite, so you can confirm the person signing is the person logged in.

The single-document signing flow in the docs is: obtain a token for signature operations, create a signer process, execute the signing (the user confirms in UAE Pass), retrieve the signed document, optionally configure long-term validation (LTV), and delete the process. There are also multi-document signing, hash signing (where only the document hash leaves your system, with Java SDK and Docker container setups), a signature verification API, and eSeal for organizational seals, which has its own certificate process depending on whether you are a Dubai or non-Dubai entity.

Signing has its own questionnaire and checklist during onboarding. If signing is core to your product, scope it as a separate workstream; check the current UAE Pass documentation for endpoints and payloads, as they differ from the authentication flow.

What are the most common UAE Pass integration pitfalls?

The UAE Pass integration issues we see most are linking users on email instead of UUID, merging UAE Pass sign-in into the local login flow, reusing credentials across channels, and small OAuth mistakes like mismatched redirect URIs or slow code exchange. Most of these fail the assessment, not just the build.

From the official guidelines and common issues page:

• Linking on email or mobile. Users can change both in UAE Pass at any time. Link on the UUID, and on Emirates ID for verified users. Store the UUID and use it for every later sign-in.
• Merging flows. “Sign in with UAE Pass” must be separate from your local login and registration flows.
• Asking UAE Pass users to create a password. Not allowed during UAE Pass registration, and you must not email or SMS them backend-generated credentials.
• Editable prefilled data. Data auto-populated from UAE Pass must be non-editable in your registration form and profile.
• Partial journeys. You need automatic linking, manual linking and new user registration covered in the same release, as applicable to your use case. Using UAE Pass for a narrow purpose only (like updating a phone number) should be avoided.
• Reusing credentials. Client credentials are channel-specific (web or mobile). Do not reuse them for another channel or use case without approval.
• Redirect URI mismatch. The redirect_uri must be identical in the authorize and token calls and match what is registered.
• Expired codes. Exchange the authorization code immediately; the docs give a 10 second window.
• Wrong token request format. Missing multipart/form-data or a malformed Basic auth header produces confusing errors.
• Button and copy. UAE Pass publishes button and error message guidelines, in English and Arabic. Follow them exactly; reviewers check.

Build these as automated tests where you can. An integration test that asserts “second login with a changed email still maps to the same account” catches the most expensive bug on this list.

How should you handle UAE Pass data under PDPL?

Treat UAE Pass attributes as sensitive personal data: Emirates ID number, names in two languages, nationality, gender, mobile and email. Collect only what your use case needs, store it encrypted, define retention, and log access. For private companies onshore, the UAE PDPL (Federal Decree-Law No. 45 of 2021) is the starting point.

Practical rules we apply on every build:

• Minimize. Request only the scopes and attributes your approved use case needs. The UUID is enough to link an account; you may not need to store the Emirates ID number at all.
• Keep secrets and tokens server-side. Access tokens and client credentials never touch logs, analytics or crash reports.
• Encrypt and restrict. Encrypt identity fields at rest and restrict who and what can read them, including AI features. If an LLM feature touches user profiles, make sure Emirates ID numbers never end up in prompts.
• Know your jurisdiction. DIFC and ADGM have their own data protection laws, and regulated sectors (banking, health) add their own rules, which can include where data is hosted. Many UAE teams choose in-country cloud regions such as Azure UAE North or AWS me-central-1 to keep things simple.
• Get legal advice. This section is engineering practice, not legal advice.

For a deeper mapping of UAE regulations to technical controls, see our guide to PDPL and NESA compliance for AI agents in the UAE.

How long does a UAE Pass integration take to build?

The code for a clean UAE Pass login is days, not weeks: an OAuth client, a callback handler, account linking logic and a few screens. The calendar time is set by onboarding: use case approval, the SPA or MOU, a recorded assessment and production checks. Plan the engineering inside that process.

In our AI-native MVP cadence, UAE Pass work slots in like this: Day 1: Spec & architecture covers the use case choice, SOP levels and linking rules (which double as your onboarding diagrams). Day 2-3: Clickable prototype gives you the wireframes the onboarding team asks for. Day 4-6: Build & test implements the flow against staging with automated tests for linking and logout. Day 7: Production launch ships the app, with UAE Pass going live once production credentials arrive. Because the approval steps are outside anyone’s control, we usually launch with your existing login and switch on UAE Pass as soon as it clears assessment.

If you are planning a UAE app with national ID login, our AI-native software development hub covers the stacks we build on, and the mobile app development cost guide for Dubai and the UAE and the Flutter vs React Native vs Kotlin Multiplatform comparison help with the decisions that come before it.