UAE Pass is the question every product team in the UAE eventually has to answer. For citizen-facing services, it is mandatory. For licensed banks, insurers, and telcos, it is increasingly expected. For real estate platforms registering Ejari tenancies, it is the only legally clean path. For any private SP looking to position itself as enterprise-credible in the UAE market, it is increasingly table stakes.
It is also the integration that consumes more engineering calendar weeks than most teams budget for. Not because the technical work is hard, but because the path from "we want to integrate UAE Pass" to "we have production credentials and a working flow" runs through a Service Provider onboarding process that operates at a different cadence to product roadmaps.
This piece is the practical engineering view from a team that has put UAE Pass through its paces across government services, regulated entities, and private SPs. We cover what UAE Pass actually is, what we have observed about the prerequisites and onboarding, the integration paths and which one your product needs, the data you actually receive, the gotchas that derail integrations, and what ongoing maintenance looks like. Where we cite specific endpoints or scope strings, we are quoting directly from the official UAE Pass documentation at docs.uaepass.ae. The operational and timeline observations are our own.
UAE Pass Path Decision Tree
Before reading further, work through the decision tree below. Pick your organisation type, then your primary use case. The tree returns the integration path you are likely to need, an indicative effort signal, and the single most common operational issue we have seen for that specific path. None of this is an official UAE Pass eligibility decision. It reflects what we have observed.
UAE Pass Path Selector
What UAE Pass Actually Is
UAE Pass is the national digital identity platform for the UAE. It is operated jointly by the Telecommunications and Digital Government Regulatory Authority (TDRA), Digital Dubai (DDA), and Abu Dhabi Digital Authority (ADDA). It provides a single digital identity credential for citizens, residents, and visitors, usable across federal government services, emirate government services, and approved private and licensed-sector services.
The technical foundation
UAE Pass is built on the OAuth 2.0 framework, with extensions for digital signing and document handling. According to the official integration documentation, Service Providers integrate against authorisation, token, user info, and logout endpoints under the id.uaepass.ae/idshub/ namespace. UAE Pass exposes three official capabilities: Authentication (available to government entities and private organisations), Digital Signature & eSeal (available to government entities and private organisations), and Data & Document Sharing (currently available to private organisations only). Document Sharing for government entities is integrated through the Government Service Bus (GSB).
For an integrating Service Provider (SP), UAE Pass behaves like a government-anchored federated identity provider. Users authenticate inside the UAE Pass mobile app, the SP receives identity attributes via standard OAuth flows, and from there the integration looks like any other federated authentication with one important caveat: the SP onboarding process is materially stricter than a commercial OAuth provider, because the underlying identity is national.
Prerequisites: Before You Write a Single Line of Code
The most expensive UAE Pass mistake we see is treating SP onboarding as a parallel track to engineering. Teams kick off the technical integration on day one, expecting credentials in a couple of weeks, and then discover they are several documents and one technical session away from a staging environment. The prerequisites below are not optional in our experience. Skipping any of them tends to result in the SP application either being rejected or stalling.
| Prerequisite | What it means in practice |
|---|---|
| Eligible legal entity | UAE-licensed entity is expected: federal or emirate government, semi-government, licensed bank or insurer or telco, or approved private SP. Free-zone tech licences are typically accepted but reviewed individually. From what we have seen, DIFC and ADGM applications fare better than smaller free zones, but every case is reviewed on its merits. |
| SP registration via TDRA | Initial approval of the request to link UAE Pass is filed via TDRA. Per the public TDRA service description, this is the consultancy and approval channel for federal government entities and the private sector linking to UAE Pass for digital transformation. |
| Authentication Integration Questionnaire | Per the public UAE Pass integration documentation, before integrating, a Service Provider must conduct an overview and technical session with the UAE Pass team, fill out the Authentication Integration Questionnaire, and install a sample UAE Pass app on SP-owned devices. This is the formal entry point to a working integration. |
| Use case justification | SP applications are reviewed in part on the use case. From what we have observed, "nice to have UAE Pass" rationales tend to struggle. The strongest cases are KYC, regulatory compliance, eligibility checks, and legally significant signing. |
| Domain ownership and HTTPS | Production and staging domains under the SP legal entity, served over HTTPS. Self-signed certificates are not accepted in our experience. |
| Privacy policy and terms of service | Should explicitly cover UAE Pass data handling, retention windows, and any third-party sharing. Alignment with the UAE Personal Data Protection Law (PDPL) is the expected baseline. Generic privacy policies copied from other markets tend to need rework. |
| Approved redirect URIs | Per the official documentation, the redirect_uri is pre-configured and registered with UAE Pass to prevent unauthorised redirects. In practice, treat the list of registered URIs as load-bearing infrastructure: every staging, UAT, and production environment should be declared as part of onboarding. |
| Realistic timeline | Plan for several weeks rather than several days. Onboarding involves a technical session, the integration questionnaire, sample app testing, and security and use-case review. We have not seen a UAE Pass integration go from cold start to production credentials inside two or three weeks. Greenfield SPs and unfamiliar use cases tend to take longer. |
The Numbers Behind the Platform
Service Provider Onboarding Flow
The SP onboarding sequence tends to be consistent in structure but variable in depth of review. Government and bank applications often run a shorter review because the licensing context is established. Private SPs face more scrutiny on the use case and data handling. Below is the operational view of how we have seen the process unfold.
Application and questionnaire
Initial approval is requested via TDRA. The technical track begins with an overview and technical session with the UAE Pass team, the Authentication Integration Questionnaire, and sample app testing on SP-owned devices. Documents typically requested at this stage: trade licence, MOA, signatory ID copies, technical architecture, data flow, privacy policy, terms of service.
Use case and security review
From what we have seen, the use case is reviewed in parallel with technical readiness. Use cases that look like a thin wrapper around sign-in convenience tend to face more pushback than ones that materially depend on verified identity. Multiple rounds of clarification are common for greenfield SPs without prior history.
Staging integration
Staging endpoints are functionally similar to production but use a separate credential set, separate redirect URIs, and a separate IP context. The official sandbox client (sandbox_stage) is documented publicly and is intended for integration testing. Build the full flow end-to-end in staging: authorisation, token exchange, user info, logout. Common issues we have seen at this stage include redirect URI mismatches, scope handling, and session lifetime assumptions.
Production credentials and go-live
Production credentials are issued after staging acceptance. Production endpoints, redirect URIs, and supporting configuration are separate from staging: there is no shared configuration and hard-coding any of it is a release-day failure pattern we have seen more than once. Use environment-driven configuration from day one.
The Two Integration Paths
UAE Pass exposes two practical integration paths for most teams: authentication-only, and authentication combined with signing. Which one you need is a function of what your service does, not what your team prefers.
Authentication only
The default path for most integrations. The user authenticates through the UAE Pass mobile app. The SP receives the user's identity attributes via standard OAuth flows. This is sufficient for sign-in, KYC for most regulated activities, eligibility checks, and any service whose output is not a legally signed document.
Authentication-only does not produce a legally binding signature. If your output is a contract, regulatory submission, or any document that needs to stand up in court or in front of a regulator as user-signed, authentication-only is not enough on its own.
Authentication plus Digital Signature & eSeal
Required where the output is a legally significant signed document. Per the official UAE Pass capabilities, Digital Signature & eSeal is the named capability for legally binding document signing. From the integration side, this typically requires the appropriate signing scopes to be assigned to the SP record by the UAE Pass team, in addition to the authentication scopes.
The signing flow is its own workstream. Signing scopes are assigned separately to your SP record after the authentication integration is in place. Treat the signing path as a follow-on integration rather than a single combined launch, and start the conversation with the UAE Pass team early.
Decision rule we use with clients: if your output is identity, integrate authentication-only. If your output is a signed document with legal effect, plan for the signing flow as well. If you need both, sequence them: get authentication live first, then layer signing.
Profile Data You Actually Receive
Many integrations design for data they assume UAE Pass returns and then discover at staging that they have been planning around the wrong attributes. Below is what we typically see returned, and what requires extended scopes.
Standard profile scope
Per the public UAE Pass integration docs, the standard profile scope is urn:uae:digitalid:profile:general. It returns the core identity attributes for the authenticated user.
Extended scopes
Additional scopes can be assigned by the UAE Pass team where the use case justifies it. Scope strings outside the documented sample are shared with the SP team during onboarding rather than published publicly. Adding scopes after go-live is harder than getting them right at the start.
Visitor flows
Per the docs, visitors (non-Emirates ID holders) follow a specific authentication path that returns a unifiedID and profileType to indicate they are a visitor. Treat visitor users as a distinct identity surface with reduced attribute coverage.
Authorisation request: the OAuth contract
The authorisation request is documented publicly on docs.uaepass.ae. Below is the staging authorisation URL pattern as documented. State protects against CSRF, scope is the standard profile scope, and acr_values indicates the requested authentication condition.
https://stg-id.uaepass.ae/idshub/authorize
?response_type=code
&client_id={your_sp_client_id}
&scope=urn:uae:digitalid:profile:general
&state={cryptographic_random}
&redirect_uri={your_registered_redirect}
&acr_values=urn:safelayer:tws:policies:authentication:level:low
# Production swaps stg-id.uaepass.ae for id.uaepass.ae
# The mobile-on-device flow uses
# acr_values=urn:digitalid:authentication:flow:mobileondevice
#
# Source: docs.uaepass.aeThe full set of supported acr_values, error codes, signing-flow scope strings, and mobile app-to-app integration parameters are documented publicly. For any production integration, treat docs.uaepass.ae as the canonical source of truth and this article as commentary.
Common Gotchas
The list below is not exhaustive but it covers the issues we have seen most often. Most of them are operational rather than protocol-level: the OAuth flow is well documented, but the surrounding lifecycle is where teams lose time.
Stable identifier choice
Use the unifiedID returned by UAE Pass as the primary key in your user database, not Emirates ID. Emirates ID changes on renewal. Integrations that key on Emirates ID are the ones we have seen lose users at renewal time.
Redirect URI lockdown
Every redirect URI is registered with UAE Pass at onboarding. Adding a new staging environment, a new mobile app variant, or a new test domain mid-project means coming back through a registration step. List every URI you might possibly need from the start.
State parameter usage
State protects against CSRF and can carry post-auth redirect context. Validate it on every callback. Skipping or mis-handling state is a class of bug that does not appear until you are testing edge flows.
Session lifetime mismatch
UAE Pass sessions and your application sessions have different lifetimes. Don't tie your application session to the access token lifetime. Handle session and refresh independently.
Staging-to-production drift
Credentials, endpoints, and registered URIs all differ between environments. Hard-coding any of them creates a release-day failure. Use environment-driven configuration with no shared constants between staging and production.
Mobile app-to-app handling
Mobile integrations that launch the UAE Pass app via custom URI schemes need explicit handling for success and failure callback URLs, as documented in the official mobile integration guide. WebView-based flows have their own constraints. Plan the mobile path as a distinct workstream from web.
Logo and branding requirements
The UAE Pass app shows the SP service name and logo in its consent screen. Logos need to meet the official UAE Pass Buttons Guidelines and Standards published on dgov.tdra.gov.ae. Non-compliant logos prevent the user-facing flow from looking professional.
Arabic-first UX
Profile data returns in both English and Arabic. RTL support, correctly displayed Arabic names, and Arabic error messages are expected. English-only flows tend to need rework.
Treat SP setup as critical path
The protocol is documented and the integration is straightforward once credentials exist. The time-consuming part is the SP setup itself. Apply early, work in staging while you wait, and treat the production date as an output discovered at the end of onboarding rather than an input you commit to a client.
Ongoing Maintenance Once You're Live
UAE Pass is not "integrate and forget." There are real ongoing obligations that should be planned into the operating model from go-live, not bolted on after the first incident.
Endpoint and parameter updates. Per the docs.uaepass.ae versioning page, the platform releases versioned changes. Subscribe to the SP communications channel and treat updates as work items, not optional reading.
Credential rotation. Client credentials and signing keys rotate over time. Build credential rotation into your normal application maintenance cycle.
Scope and capability updates. New capabilities and attributes are added to the platform over time. Reviewing the platform changelog periodically is the cheapest way to stay current.
Compliance with PDPL and sector regulation. The UAE Personal Data Protection Law (PDPL) applies to UAE Pass data the same way it applies to any personal data. Sector-specific regulators (CBUAE, DFSA, FSRA, DHA, and others) layer on top. Your data handling needs to satisfy both.
Where We Get Called In
UAE Pass engagements typically fall into two categories. Greenfield work is the cleaner case: a service is being built from the ground up, the integration is part of the architecture from day one, and the SP onboarding runs alongside the engineering build. This shape applies across government services, regulated banks, and licensed-sector platforms.
Rescue work is the second category. An integration exists, it is not working, and the team needs a fix. The pattern is consistent: SP application stuck in review, production gotchas that did not surface in staging, performance issues at the token endpoint, or session and refresh handling that is failing under real load. We have come into rescue projects at every stage from "stuck in onboarding" to "in production but losing users at the consent screen."
If you are scoping a UAE Pass project, the most useful first conversation is usually 45 minutes on the use case and the timeline. We can typically tell within that conversation which integration path you need, what the realistic onboarding window looks like, and where the budget exposure sits. Get in touch if that would be useful, or read more about our UAE Pass integration platform work, our broader citizen portal development practice, and our government compliance platform work. For banking and insurance teams, the cross-vertical view is in our KYC onboarding platform work.
Frequently Asked Questions
Yes, but reviewed individually. From what we have seen, DIFC and ADGM entities tend to have an easier path when the use case is clear, particularly for KYC, customer onboarding for regulated activity, and document signing. Smaller free zones tend to require more justification. The deciding factor in our experience is the use case, not the licence type. A free-zone fintech doing customer KYC is on stronger ground than a free-zone marketing agency wanting UAE Pass for sign-in convenience. Have your trade licence, MOA, and a precise use case write-up ready before applying.
We do not give specific week numbers because the lead time varies materially with entity type, use case, and TDRA queue depth at the time of application. Our consistent advice is to plan for several weeks rather than several days, and to apply at the start of the project rather than at the end. Federal entities and major banks tend to move through the process faster in our observation, and greenfield private SPs without prior TDRA history tend to take the longest. Do not commit a launch date to a stakeholder before you have production credentials in hand.
Authentication-only proves the user is who UAE Pass says they are and returns identity attributes. It is sufficient for sign-in, most KYC use cases, and eligibility checks. The signing flow combines authentication with the official Digital Signature & eSeal capability, which produces a legally binding signed output. Required for any output that needs to stand up legally, including contracts, regulatory submissions, Ejari registrations, and similar. Signing requires additional scopes to be assigned to your SP record by the UAE Pass team, and is best treated as a separate workstream that follows the authentication integration.
UAE Pass is a strong KYC input but it is not a complete CDD framework on its own. It returns verified identity attributes. What it does not return is a risk rating, a sanctions check, a PEP screening, or any adverse media flag. CBUAE-licensed entities and other financial sector operators are still expected to layer their own CDD on top of UAE Pass identity. For non-financial KYC use cases (eligibility checks, customer onboarding for regulated activity, age verification) UAE Pass on its own is often sufficient. Confirm with your sector regulator before treating it as a full KYC substitute.
Profile attributes are returned on each authentication call. There is no push notification from UAE Pass when a user's editable details change. If your application needs current data, refresh on every sign-in and avoid caching profile data indefinitely. Keying your user records on the unifiedID returned by UAE Pass (rather than on Emirates ID) is the cleanest way to handle Emirates ID renewals without losing the link to the user.
UAE Pass integration is one of the most consequential identity decisions a UAE-facing product makes. Get it right and the integration becomes invisible: users sign in, KYC happens, documents get signed, and the platform reaches the audience it needs to reach. Get it wrong and the project becomes a long retrospective on why the SP review did not move at the pace the roadmap assumed. The difference is almost always preparation, not engineering. The teams that move fastest are the ones that started the SP application on day one.
UAE Pass integration specifics, endpoints, scope strings, and SP onboarding requirements may change. Treat docs.uaepass.ae as the canonical reference. Operational observations in this article reflect the experience of our own delivered integrations and are not official UAE Pass guidance. References to UAE Pass, TDRA, Digital Dubai, Abu Dhabi Digital Authority, and any other named bodies are descriptive only and do not imply endorsement, partnership, or affiliation. Public sources used in this piece are listed on our Sources and Data page.
Ready to Build Something?
If this resonated, let's talk about how we can apply these ideas to your business.
Start a Conversation