UAE PASS login in your app: the onboarding phases and what to plan before you apply

What UAE PASS login does, and which accounts reach your app

UAE PASS is the UAE digital identity service, with a mobile app that users confirm logins in. Its documentation lists three capabilities: authentication and digital signature for government entities and private organisations, and data and document sharing for private organisations only. This post covers authentication, the "Sign in with UAE PASS" button.

Not every UAE PASS user is the same. The docs describe three account types. SOP1 is a basic, unverified account, which can be created without an Emirates ID. SOP2 is verified and SOP3 is verified with biometrics. Authentication supports all three, but for SOP1 users UAE PASS does not return the Emirates ID number. Decide early what an unverified user may do in your app. UAE PASS publishes the exact error message, in English and Arabic, for turning such a user away.

The four onboarding phases

The phases come from the UAE PASS service provider onboarding pages. Nothing here has a published duration, so I would not promise a launch date that depends on them.

What to have ready before you press submit

Most of the initiation pack is design work, not code. The use case guidelines say your diagram should follow one of their standard scenarios and quote its reference number. A use case that departs from those scenarios needs management approval, which UAE PASS warns can extend the process. My advice is to pick a standard scenario unless you truly cannot.

• Entity type (Government or Private) and, for a private company, a valid UAE trade licence
• The features you need: authentication only, or signing and document sharing too
• The standard use case number your journey follows
• A workflow diagram from the login button to the logged-in screen, including new and existing users
• Wireframes for every UAE PASS screen, using the official button assets and design guidelines
• Redirect URLs for web and, for mobile, your app's own URI scheme
• Who in your company signs the Service Provider Agreement
• Your rule for unverified (SOP1) users and visitors

The login flow: OAuth 2.0 against UAE PASS endpoints

UAE PASS authentication is based on OAuth 2.0 with an authorization code. Your app sends the user to the authorize endpoint with your client ID, scope, state and redirect URL. A ui_locales value of ar or en picks the Arabic or English login page. The user enters an email, mobile number or Emirates ID and confirms a push notification in the UAE PASS app. Your redirect URL then receives a code.

That code is single use and short-lived, so exchange it straight away. The token call uses Basic authentication with your client ID and secret, and the user info call uses the access token. UAE PASS says both should be back-channel requests. In a mobile app, I would make them from your backend, never from the app, because a client secret inside an app binary is not a secret. Staging runs on stg-id.uaepass.ae and production on id.uaepass.ae, with separate credentials for each.

User info returns, where applicable, a uuid, names in English and Arabic, email, mobile, and for verified users the Emirates ID number.

Mobile apps: the app-to-app flow is its own piece of work

On a phone, UAE PASS expects the login to run in a WebView inside your app, not the system browser. The app checks whether UAE PASS is installed (on Android by package ID, on iOS by URL scheme, with different values for staging and production). If it is, you load the login URL with the mobile-on-device acr value, watch the WebView for the UAE PASS deep link, rewrite its success and failure URLs to your own app's scheme, and open UAE PASS. When the user confirms, UAE PASS calls your scheme back and you load the saved success URL in the same WebView to finish. If UAE PASS is not installed, the user logs in on the web page and confirms on another device.

The docs warn you to register your own scheme, not the demo app's, or redirects can land in another provider's app. In a Flutter app this means a WebView with URL interception plus deep link handling on both platforms. I would scope and test it as its own item on real Android and iOS devices, in staging and again in production, with UAE PASS installed and not installed.

Account linking: link on UUID, not on email

UAE PASS users can change their email and mobile number at any time. If you match accounts on those, the link breaks and you end up with duplicate users. The docs say to link on the UAE PASS UUID, or the Emirates ID for verified users. Store the UUID once on the first login and use it after that.

The implementation guidelines add rules the assessment checks. UAE PASS login must stay separate from your own login and registration flows. Existing users either link automatically on a unique verified attribute or link manually by signing in with their old credentials once. New users get your registration form prefilled from UAE PASS, and those UAE PASS fields must not be editable, in the form or in the profile later.

Where UAE PASS fits in my packages

I would not add UAE PASS to an app without its own backend, because the token exchange needs somewhere safe to hold the client secret. That rules out Launch ($999) on its own. Growth ($1,699) includes a Node.js backend and PostgreSQL database with user accounts. Scale ($2,500) adds the admin dashboard and integrations with the services you use. Either way, UAE PASS goes into the written scope as a named integration before work starts, and specialised compliance work is quoted separately.

The onboarding approvals belong to the UAE PASS team, and the trade licence and agreement are yours to provide. I can prepare the diagram, wireframes and recordings with you, build against staging, and support the assessment. I cannot guarantee their approval or its timing.