UAE Pass API Integration Guide for Developers

UAE Pass API integration means implementing OpenID Connect on top of OAuth 2.0: redirecting users for authentication, exchanging the authorization code for tokens on your backend, validating the ID token, and retrieving identity attributes based on the SOP level your application requires. This applies to any platform requiring Emirates ID-verified or biometric-assured identity — banking onboarding, insurance applications, property platforms, HR systems, government portals, and fintech products are the most common production cases.

Jump to: What Is UAE Pass? · Authentication Architecture · SOP Levels · The OAuth 2.0 Flow · Sandbox Setup · Common Errors · Web vs. Mobile SDK · Security Requirements · Production Approval · Recommended Tech Stack · 7 Mistakes That Delay Approval · Cost · Summary · FAQ

What Is UAE Pass?

UAE Pass is the UAE government's national digital identity platform, issued jointly by the Telecommunications and Digital Government Regulatory Authority and Smart Dubai. It gives residents and citizens a single verified identity — tied to their Emirates ID — that private and public sector applications can use instead of building and maintaining their own identity verification. For a developer, integrating UAE Pass means the application never stores a password or handles identity-document verification directly; it delegates that entirely to UAE Pass and receives back a signed token confirming who the user is and how strongly that identity was verified. Adoption spans banking, insurance, healthcare, telecom, government services, and fintech, and it's increasingly a hard requirement rather than an option for any UAE-facing application that touches regulated onboarding.

Authentication Architecture

UAE Pass sits in front of your application as an identity provider, following the standard OpenID Connect pattern: your application (the relying party) never sees the user's UAE Pass credentials. Instead, the user is redirected to UAE Pass to authenticate, and your backend receives a short-lived authorization code that it exchanges — server-side, never from the browser — for an access token and an ID token. The ID token is a signed JSON Web Token carrying the user's verified attributes at whatever SOP level your application requested. Everything downstream of that exchange (session creation, attribute storage, re-authentication policy) is the application's own responsibility; UAE Pass's job ends at issuing a verifiable identity assertion.

SOP Levels

UAE Pass defines three Service Operating Procedure levels, and the level you request determines both what identity data you get back and how much friction the user goes through to authenticate. Choosing the wrong level is one of the most common integration mistakes — requesting more assurance than a feature needs slows down onboarding for no benefit, and requesting too little gets an application rejected during production approval review.

SOP1 – Basic Identity

SOP1 confirms that a UAE Pass account exists and returns basic profile information without requiring Emirates ID verification at the point of login. It's appropriate for basic portal access, information services, non-regulated applications, and marketing platforms — anywhere the application needs to know who a returning user is but isn't making a regulated decision based on that identity.

SOP2 – Emirates ID Verified

SOP2 confirms the user's identity against their Emirates ID and is the level most production business applications request. This is the level that covers banking onboarding, insurance applications, property platforms, HR systems, government portals, and fintech products — anywhere a business needs confidence that the person behind the account is who they claim to be, without requiring the heavier biometric step.

SOP3 – Biometric Assurance

SOP3 adds biometric confirmation on top of Emirates ID verification and is reserved for the highest-risk actions: sensitive financial transactions, high-value approvals, legal authorizations, government transactions, and secure document signing. Most applications only need SOP3 for specific actions within an otherwise SOP2 flow, rather than for every login — stepping up to SOP3 only at the moment a high-risk action is requested keeps the everyday experience faster without weakening protection where it matters.

The Complete UAE Pass OAuth 2.0 Flow

The user selects "Login with UAE Pass" inside your application, which redirects their browser to the UAE Pass authorization endpoint with your client ID, requested scope, requested SOP level, redirect URI, and a state parameter your backend will verify on return.

Step 2: UAE Pass Authentication

UAE Pass handles the actual authentication — password, OTP, or biometric, depending on the SOP level requested and the user's own UAE Pass app configuration. Your application has no visibility into this step and should not attempt to replicate any part of it.

Step 3: Authorization Code Return

Once authentication succeeds, UAE Pass redirects the browser back to your registered redirect URI with a short-lived authorization code and the state parameter you originally sent. Verifying that the returned state matches what you sent is a required check, not an optional one — skipping it is a common source of the "Authorization Code Already Used" and CSRF-adjacent issues developers run into later.

Step 4: Access Token Exchange

Your backend exchanges the authorization code for an access token and an ID token by calling the UAE Pass token endpoint directly, server-to-server, using your client credentials. This exchange must happen from your backend, never from client-side JavaScript, since it requires your client secret.

Step 5: Validate the ID Token

Before trusting anything in the ID token, your backend validates its signature against UAE Pass's published keys, confirms the issuer and audience claims match your configuration, and checks that the token hasn't expired. Skipping validation and simply trusting a decoded token is one of the more serious integration mistakes, since it removes the entire security guarantee OpenID Connect is providing.

Step 6: Retrieve User Profile Data

With a validated token, your backend calls the UAE Pass user info endpoint to retrieve the identity attributes available at the requested SOP level — name, Emirates ID number, nationality, and other fields depending on scope. This is the point where your application should create or update its own user record and establish its own session; UAE Pass's involvement in that particular login is complete.

Need UAE Pass integrated without burning a sprint on SOP levels and production approval? Pixbit scopes UAE Pass integration in a single discovery session — let's talk.

Sandbox Environment Setup

Sandbox Registration

Development starts with registering for UAE Pass sandbox access, which issues a separate set of client credentials scoped to the test environment rather than production. Sandbox and production credentials are never interchangeable, and treating them as such during a rushed deployment is a reliable way to fail production review.

Sandbox Mobile Application

UAE Pass provides a dedicated sandbox mobile application for testing the authentication flow end-to-end without needing real Emirates ID-linked accounts, which lets a development team validate the full OAuth exchange, token handling, and profile retrieval before any production approval process begins.

Callback URL Configuration

Every redirect URI your application will use — including local development URLs, staging URLs, and the eventual production URL — needs to be registered with UAE Pass in advance. A mismatch between the redirect URI sent in the authorization request and what's registered is one of the most common errors developers hit, and it needs to be fixed on the UAE Pass registration side, not worked around in code.

Common Errors Developers Encounter

Invalid Redirect URI

This occurs when the redirect URI sent in the authorization request doesn't exactly match a URI registered for your client — including scheme, trailing slashes, and port number for local testing. The fix is always to align the registration, not to loosen validation on your own side.

Invalid Client Credentials

Usually caused by sandbox credentials being used against the production endpoint or vice versa, or by a client secret that was rotated on the UAE Pass side without being updated in the application's configuration.

Authorization Code Already Used

Authorization codes are single-use and short-lived by design. This error typically shows up when a page reload or a duplicate callback request causes the same code to be exchanged twice, which is why idempotent handling of the callback route matters.

Invalid Scope

Requesting profile attributes that aren't available at the SOP level your client is approved for returns this error rather than silently omitting the field — which is why the SOP level decision in the earlier section needs to be made deliberately, not left as a default.

Token Validation Failure

Almost always traces back to a signature check against the wrong key set, a clock skew issue between servers when checking token expiry, or an audience claim that doesn't match the client ID making the request.

User Profile Retrieval Errors

These typically follow a token validation issue rather than being independent — if the ID token didn't validate cleanly, the profile call built on top of it is very likely to fail as well.

Web Integration vs Mobile SDK Integration

Web Applications

Web integration follows the OAuth 2.0 authorization code flow described above directly, with the browser redirect handled by standard web navigation and the token exchange happening from your server. This is the simpler of the two integration paths and is usually where a new UAE Pass integration should start, even for a product that will eventually ship native mobile apps.

Mobile Applications

Mobile integration uses UAE Pass's native SDKs for iOS and Android, which handle the redirect to the UAE Pass mobile app (or a web fallback if it isn't installed) and return control to your application via a custom URL scheme or universal link rather than a standard web redirect. The underlying OAuth exchange is conceptually the same, but the SDK abstracts the redirect handling in a way that needs platform-specific configuration on both the UAE Pass registration side and inside the mobile app itself.

Security Requirements Developers Should Implement

Use PKCE Where Supported

Proof Key for Code Exchange adds a cryptographic binding between the authorization request and the token exchange, which closes a class of interception attacks against the authorization code — worth implementing even where UAE Pass doesn't strictly require it for your client type.

Validate Every Token

Every ID token needs signature, issuer, audience, and expiry validation on every request — not just at initial login. A cached or partially-validated token is a security gap, not a performance optimization.

Encrypt Sensitive User Data

Emirates ID numbers and other identity attributes retrieved from UAE Pass should be encrypted at rest in your own database, following the same standard you'd apply to any other sensitive personal data under UAE data protection expectations.

Log Authentication Events

Authentication successes, failures, and token validation failures should be logged with enough detail to support an audit trail, both for your own security monitoring and because UAE Pass's production approval review will ask about this directly.

Production Approval Requirements

Service Provider Assessment

UAE Pass reviews the business case for your integration — what SOP level you're requesting and why, matched against the actual use case — before granting production access. Requesting SOP3 for a use case that clearly only needs SOP2 is a common reason this step gets delayed.

Security Review

A review of how your application handles tokens, stores identity data, and implements the security requirements above. This is typically where an integration that skipped PKCE, token validation, or encryption gets sent back with required changes.

Domain Verification

Your production domain needs to be verified as under your control before UAE Pass will issue production credentials against it, which is a separate step from registering the callback URL itself.

User Journey Review

UAE Pass reviews the actual login experience — where the "Login with UAE Pass" option appears, how errors are surfaced to the user, and whether the flow matches UAE Pass's own branding and UX guidelines for the button and messaging.

Recommended Technology Stack

Backend

Any backend capable of making server-to-server HTTPS calls and validating JWTs works — Pixbit typically builds this layer in Laravel for UAE Pass integrations, since token exchange, validation, and session management map cleanly onto Laravel's existing authentication middleware.

Frontend

The frontend's job is limited to triggering the redirect and handling the return — a React or Next.js frontend needs no UAE Pass-specific logic beyond that, since the actual identity exchange happens entirely on the backend.

Mobile

Flutter applications integrate the native UAE Pass SDKs through platform channels, keeping the same backend token-exchange logic shared with the web application rather than duplicating it in the mobile client.

Infrastructure

Sandbox and production need genuinely separate configuration — separate client credentials, separate redirect URIs, and ideally separate environment variables enforced at the infrastructure level, so a misconfigured deploy can't accidentally point production traffic at sandbox credentials or the reverse.

7 Mistakes That Delay Production Approval

Requesting a higher SOP level than the use case requires is the single most common delay, since it invites deeper scrutiny during service provider assessment for no functional benefit. Skipping ID token signature validation is the second most common, and it's a security review failure every time it's caught. Reusing sandbox client credentials in a production build, even temporarily, will fail domain verification outright. Not registering every redirect URI variant — including any staging or QA environment — causes integration failures that look like UAE Pass errors but are actually registration gaps. Storing Emirates ID numbers or other identity attributes without encryption at rest is a security review blocker on its own. Building the "Login with UAE Pass" experience without following UAE Pass's UX and branding guidelines triggers user journey review pushback. Treating the mobile SDK integration as an afterthought after the web flow ships, rather than planning both from the start, tends to surface architecture problems late enough to cost real time.

How Much Does UAE Pass Integration Cost?

Cost depends on which SOP levels the application needs, whether both web and mobile SDK integration are in scope, and how much of the surrounding identity infrastructure (session management, encrypted storage, audit logging) needs to be built alongside the integration itself rather than already existing. Pricing runs in a AED range that scales with that scope rather than a single fixed figure — Pixbit scopes the actual number in a single discovery session once the SOP level and platform requirements are clear.

Summary: UAE Pass API Integration Steps

Step	What Happens	Where It Runs
SOP level selection	Determines what identity data is returned and how much friction the user experiences.	Decided during design, before any code is written.
Authorization redirect	User is sent to UAE Pass to authenticate.	Browser / mobile app, via standard redirect or native SDK.
Authentication	UAE Pass handles password, OTP, or biometric verification.	Entirely on UAE Pass's side.
Authorization code return	UAE Pass redirects back with a short-lived code and state parameter.	Browser redirect back to your registered URI.
Token exchange	The authorization code is exchanged for an access token and ID token.	Server-to-server, from your backend only.
Token validation	Signature, issuer, audience, and expiry are checked before trusting the token.	Your backend.
Profile retrieval	Identity attributes are pulled from the UAE Pass user info endpoint.	Your backend, using the validated access token.
Production approval	Service provider assessment, security review, domain verification, and user journey review.	UAE Pass's approval process, before go-live.

Frequently Asked Questions

What is UAE Pass and why do applications need to integrate with it? UAE Pass is the UAE government's national digital identity platform. Applications integrate with it to verify a user's identity against their Emirates ID — or with biometric assurance for higher-risk actions — without building and maintaining their own identity verification system.

What's the difference between SOP1, SOP2, and SOP3? SOP1 confirms a UAE Pass account exists without Emirates ID verification at login. SOP2 verifies the user against their Emirates ID and covers most production business applications. SOP3 adds biometric confirmation and is reserved for high-risk actions like financial transactions and legal authorizations.

Do I need separate credentials for sandbox and production? Yes. UAE Pass issues distinct client credentials for its sandbox and production environments, and they are never interchangeable — using sandbox credentials in a production build will fail domain verification.

What's the most common reason production approval gets delayed? Requesting a higher SOP level than the actual use case requires, which triggers deeper scrutiny during service provider assessment. Skipping ID token signature validation is the second most common cause, and it's flagged during security review every time.

Does UAE Pass integration work differently for web and mobile? The underlying OAuth 2.0 exchange is the same, but mobile applications use UAE Pass's native iOS and Android SDKs to handle the redirect, while web applications use a standard browser redirect. Most integrations should start with the web flow before adding mobile SDK support.

How much does UAE Pass integration cost? Cost depends on which SOP levels are needed, whether both web and mobile are in scope, and how much surrounding identity infrastructure needs to be built. Pixbit scopes the specific figure in a single discovery session.

Why Pixbit Solutions

Pixbit has built UAE Pass integrations across web and mobile for UAE-facing platforms, on the same Laravel, React, Next.js, and Flutter stack recommended above. That means the SOP level decision, token validation, and production approval checklist are handled by a team that has been through UAE Pass's review process before, rather than treated as a first attempt.

Getting Started

Need UAE Pass integrated into your platform — web, mobile, or both? Pixbit scopes UAE Pass integration in a single discovery session — let's talk.

UAE Pass Integration Guide for Developers: OAuth 2.0 Flow, Sandbox Setup, and the Common Mistakes That Will Block Your Production Approval