# Nafath Integration for Saudi Applications: What Engineering Teams Need to Know
Short answer: Nafath is Saudi Arabia's national single sign-on. It lets an application
authenticate a user against their verified national identity instead of building its own
identity proofing. Integration is an OAuth/OIDC-style federated flow with government
onboarding attached, and the engineering work is usually smaller than the approval process
that precedes it.
---
What Nafath actually is
Nafath is Saudi Arabia's national single sign-on, launched in 2021 and operated by the
National Information Center under SDAIA. Rather than asking a user to upload an ID document
and waiting for a manual review, an application redirects the user to Nafath, the user
confirms through the Nafath app, and the application receives government-verified identity
attributes.
The scale is worth understanding before you decide whether to integrate. Saudi Arabia's
national SSO fronts access to [more than 6,000 government and private
services](https://my.gov.sa/en/content/173), and by 2026 over 150 platforms use Nafath as
their identity provider. The Digital Government Authority mandates it for identity
verification on government online services, and password-based login to government portals
has largely been retired in its favour.
For a Saudi user, this means Nafath is not an unfamiliar third-party login button. It is
the way they already authenticate to their bank, their telecom operator and their
government. An application that offers it is meeting an established expectation; one that
does not is asking the user to do something they have stopped doing elsewhere.
For a product team, the meaningful consequence is this: identity proofing stops being your
problem. You are no longer storing ID scans, building a review queue, or carrying the
liability of a document verification process. You are consuming an assertion from the
authority that issued the identity in the first place.
That is a substantial reduction in both build cost and risk surface, and it is why Nafath
integration is effectively expected for anything government-facing, and increasingly for
regulated private-sector services.
---
When you need it — and when you do not
You almost certainly need Nafath if your product is government-facing, is a regulated
financial service, handles a high-assurance transaction (property, licensing, health
records), or if your users would reasonably expect to sign in the way they sign in to other
Saudi services.
You probably do not need it if you are building a consumer app where an email address is
a sufficient identity, or if a meaningful share of your users are not Saudi nationals or
residents — Nafath authenticates people who hold a Saudi identity, so it cannot be your only
authentication route for an international user base.
The common architecture is Nafath alongside a conventional authentication method, not
instead of it. Design for that from the start; retrofitting a second identity provider into
a system that assumed one is painful.
---
The integration shape
The flow will be familiar to anyone who has integrated a federated identity provider:
1. Your application requests authentication for a given national ID.
2. The user is prompted through Nafath — typically confirming a displayed number in the
Nafath mobile app.
3. The user approves.
4. Your application receives the authentication result and the identity attributes you are
authorised to receive.
5. You establish your own session from that result.
Nafath supports standard federation protocols — OpenID Connect and SAML 2.0 — so the
protocol layer is well-trodden ground for any team that has integrated an enterprise
identity provider. The mechanics are not the hard part. The parts that consume schedule are:
Onboarding and approval. These are not open APIs and there is no dashboard that issues
you a key. Access is granted by application to the National Information Center, and the
application is substantive: you submit technical architecture, demonstrate your platform's
security posture, and justify why your service needs access to citizen identity data.
Eligibility generally requires a registered local entity and a legitimate use case, and some
attributes are restricted by sector.
Start this the day the project is approved, not the day the integration is code-complete.
The technical work is a few weeks; the approval cycle is measured in months and engineering
cannot accelerate it. This ordering mistake — building first, applying second — is the most
common way a Nafath-dependent launch date slips.
Testing against staging. NIC provides a sandbox with mock data and simulated Nafath app
approvals. Build against it, and specifically exercise the paths that are awkward to
reproduce later: approval timeout, user rejection, and a user who does not complete the
out-of-band step at all.
Attribute minimisation. Request the narrowest set of attributes that your use case
actually needs. Asking for more slows approval and increases your data protection
obligations under the Saudi PDPL. "We might need it later" is not a justification that
survives review.
The out-of-band confirmation step. The user leaves your interface to approve in a
separate app. That is a real UX discontinuity: users switch away, get distracted, time out,
or approve after your session expired. Handle the timeout path explicitly, make the pending
state legible, and let the user retry without starting over.
Failure and fallback. A user without the Nafath app, a user whose approval times out, a
platform outage. Each needs a defined path. An authentication route with no fallback is an
availability risk sitting in front of your entire product.
---
Data protection considerations
Nafath returns verified personal data about an identified individual, which places it
squarely inside Saudi PDPL obligations. Practical implications:
- Store the minimum. Receiving an attribute does not mean persisting it. Often you need
the verification event and a stable identifier, not the underlying data.
- Be explicit about retention. Decide, document, and implement how long identity
attributes are held, and delete on that schedule rather than by intention.
- Consider residency. Where the data lands matters for PDPL and, for some sectors,
for cloud classification requirements. Decide deployment region deliberately.
- Log the assertion, not the payload. Audit trails need to show that verification
occurred; they rarely need to contain the verified attributes themselves.
---
What this costs you in practice
The API integration is genuinely modest — a federated authentication flow is well-trodden
ground. Budget realistically for the surrounding work instead:
- Government onboarding and approval, which you do not control the timing of
- A second authentication path for users outside Nafath's scope
- Arabic-first interface work in the authentication journey, which is where users are least
tolerant of an awkward translation
- PDPL-shaped decisions about storage, retention and residency
- The failure and timeout paths, which is where most of the real engineering lives
Teams that under-estimate Nafath almost always do it by scoping the API call and forgetting
everything around it.
---
Frequently asked questions
What is Nafath used for?
Nafath is Saudi Arabia's national single sign-on and identity verification service. It lets
an application authenticate a user against their verified national identity, removing the
need to build and operate your own document-based identity proofing.
Can Nafath be the only login method in my app?
Only if every user holds a Saudi national identity. Nafath authenticates Saudi nationals and
residents, so an application serving international users needs a second authentication path
alongside it.
How long does Nafath integration take?
The authentication flow itself is a standard federated integration. The schedule is usually
set by government onboarding and approval, which you should begin as early as possible, plus
the fallback paths, Arabic interface work and PDPL decisions around it.
Does Nafath integration have PDPL implications?
Yes. Nafath returns verified personal data about an identified individual, so retention,
minimisation and residency decisions all fall under Saudi PDPL. Request the narrowest
attribute set your use case needs and store the verification event rather than the payload
wherever you can.
---
*This guide describes the shape of a Nafath integration for planning purposes. Onboarding
requirements and available attributes are set by the operating authority and change —
confirm current requirements through official channels before committing to a design.*