Introduction
Identity is the new perimeter. As organizations across the UAE(United Arab Emirates) accelerate their digital transformation journeys, the question of how users authenticate — and which identity they bring — is becoming as important as the applications themselves. UAE PASS, the UAE’s national digital identity platform, is at the heart of this shift. It allows residents and citizens to authenticate to digital services using a single, government-verified digital identity — verified against Emirates ID, mobile, and email.
I recently had the opportunity to integrate UAE PASS as an Identity Provider (IdP) with Oracle Cloud Infrastructure Identity and Access Management (OCI IAM). The goal was straightforward: allow users to log in to Oracle Fusion (SaaS) applications using their UAE PASS credentials, with Multi-Factor Authentication (MFA) handled entirely by UAE PASS. This blog captures my experience — the setup, the validation, and some key observations I believe will be useful for anyone looking to explore OCI IAM Social IdP integration capabilities.
What is UAE PASS?
UAE PASS is the UAE’s nationwide digital identity and digital signature platform, built on the OAuth 2.0 framework. It allows UAE residents to authenticate using their verified digital identity across a growing ecosystem of government and private sector services.
One aspect worth highlighting is the concept of assurance levels. UAE PASS has three account types:
- SOP1 — Mobile and Email verified
- SOP2 — Mobile, Email, and Emirates ID verified
- SOP3 — Mobile, Email, and Emirates ID verified (highest assurance)
This tiered assurance model maps well to enterprise access policies where different applications may require different levels of identity confidence. This blog is focused on a SaaS application like Oracle Fusion integration with SOP1(sufficient for the POC).
The Integration Architecture
At a high level, the integration follows the standard OAuth 2.0 Authorization Code flow, with OCI IAM acting as the Service Provider (SP) and UAE PASS acting as the Identity Provider (IdP). There are three key phases:
Phase 1 — Login: The user signs in on UAE PASS and confirms it’s really them via their phone.
Redirecting the user to UAE PASS
The moment a user tries to access the Fusion application. Instead of the standard Oracle Cloud login form, the user is redirected to UAE PASS — the application hands off authentication entirely, asking UAE PASS to verify who this person is before letting them in.
Behind that redirect is a request to UAE PASS, telling it three things: which application is asking (client_id), where to send the user back afterward (redirect_uri), and how strictly to verify their identity (acr_values) — this last one determines whether email/mobile is enough, or whether Emirates ID is required too.
Having been redirected to UAE PASS, the user now identifies themselves — but unlike a typical login screen, UAE PASS doesn’t ask for a password at this stage. It only needs to know who is logging in; how they prove it comes next.
Once submitted in a browser, the UAE PASS login page is presented. The user enters their identifier (Email, Phone No or Emirates Id) and is prompted to confirm the login on their mobile app.
Phase 2 — Exchange: UAE PASS hands OCI IAM a one-time code. OCI IAM swaps that code for an access token, behind the scenes.
MFA on the UAE PASS App
This is where the experience gets interesting. The browser displays a numeric code. The UAE PASS mobile app simultaneously shows a push notification with three number choices. The user must select the matching number and confirm. This is an elegant MFA mechanism — it binds the browser session to the mobile device without requiring a one-time passcode to be typed.
After confirmation, the UAE PASS app home screen shows the authenticated profile — in this case a Basic Account (SOP1).
Phase 3 — Profile: OCI IAM uses the token to fetch the user’s verified details from UAE PASS, then signs them in — creating their account automatically if it’s their first time.
Confirming the login and signing the user in
Once user approves the request on his phone, UAE PASS sends the browser back to the application with a short-lived authorization code. Behind the scenes — not visible to user — OCI IAM exchanges that code for an access token, then uses the token to fetch his verified profile from UAE PASS: name, mobile number, nationality, and email.
If this is user’s first time logging in, OCI IAM can create his user account on the spot using these details — no IT request, no pre-provisioning. He lands straight in the OCI Console, already signed in.
Configuring OCI IAM — Why a Custom Social IdP Was Needed
OCI IAM ships with built-in connectors for well-known social providers such as Google, Facebook, Microsoft, and LinkedIn. My first instinct was to use the generic OpenID Connect type. However, UAE PASS has several characteristics (Custom authorization parameters, UAE-specific attribute names etc) that make it incompatible with the standard built-in connectors:
OCI IAM addresses all of this through its Custom Social IdP framework. Using the /admin/v1/SocialIdentityProviderMetadata REST API, I registered a new provider type named UAEPASS_2 — a custom template that defines exactly how OCI IAM should interact with UAE PASS at every phase of the OAuth flow.
This is a testament to OCI IAM’s extensibility. A national identity platform with its own government-defined protocol parameters was integrated purely through a JSON metadata registration.
Attribute Mapping and Just-In-Time Provisioning
One of OCI IAM’s most powerful capabilities in this context is Just-In-Time (JIT) Provisioning. When a user authenticates through UAE PASS for the first time, OCI IAM checks whether that user already exists in the identity domain. If not, it automatically creates the user account at login time — populated with the attributes received from UAE PASS.
The attribute mapping from UAE PASS to OCI IAM SCIM attributes is configured as part of the custom IdP definition:
| UAE PASS Attribute | OCI IAM (SCIM) Attribute(sample) |
| firstnameEN | given_name |
| lastnameEN | family_name |
| fullnameEN | displayName |
| mobile | phoneNumber |
This means that the first time a UAE resident logs into an Oracle Fusion application using their UAE PASS, their user account is created automatically in OCI IAM — with their verified name, email, and mobile number — without any pre-provisioning or IT helpdesk involvement. For enterprises onboarding UAE-based employees or customers to Oracle SaaS, this is a significant operational advantage.
Key Takeaways
Reflecting on this integration, here are the observations I found most valuable:
1. Validate first, configure second. UAE PaaS provides staging envionrment for running POC/Pilot through the full OAuth flow in Postman before touching OCI IAM saved considerable time.
Before touching any OCI IAM configuration, I validated the entire three-step flow using Postman against the UAE PASS Staging environment. This is a step I strongly recommend — it gives you confidence in the protocol-level behavior before layering in the IAM platform.
2. OCI IAM’s extensibility is a genuine differentiator. The Custom Social IdP framework allowed to accommodate every UAE PASS-specific requirement — custom parameters, non-standard scopes, custom attribute names — entirely through a JSON configuration.
3. JIT Provisioning removes friction at scale. For a platform like Oracle Fusion being deployed across a UAE organization, the combination of UAE PASS authentication and JIT provisioning means users can be on-boarded to enterprise applications simply by authenticating with their national digital identity. No batch imports, no pre-provisioning workflows.
4. The UAE PASS MFA experience is well-designed. The number-matching mechanism between browser and mobile app is intuitive and resistant to phishing — the user must physically confirm a specific code, not just approve a generic push notification. From an IAM perspective, this is a strong out-of-the-box MFA posture.
5. Staging environment is production-ready for POC. The UAE PASS staging environment faithfully mirrors the production flow. The Postman collection available from the UAE PASS documentation accelerates the initial validation considerably.
Conclusion
UAE PASS represents a significant step forward in the UAE’s digital identity landscape. For organizations running Oracle Fusion or other OCI-hosted applications, the ability to federate authentication to UAE PASS means users can bring their government-verified national identity to enterprise applications — with strong MFA built in.
OCI IAM’s Custom Social IdP framework makes this integration achievable, while JIT Provisioning ensures the user lifecycle is handled seamlessly at scale. Together, they deliver a modern, standards-based identity architecture that aligns well with the UAE’s digital government vision.
If you are exploring UAE PASS integration for your Oracle environment, I hope this walkthrough gives a clear starting point.
Reference links:
- UAE PASS Documentation: https://docs.uaepass.ae
- OCI IAM Custom Social IdP: https://docs.oracle.com/en-us/iaas/Content/Identity/api-getstarted/customSocialIDPs.htm
- UAE PASS Staging POC Guide: https://docs.uaepass.ae/quick-start-guide-uae-pass-staging-environment/conduct-a-poc-with-uae-pass-authentication