Skip to content
AIMOCS

AIMOCS · Saudi & MENA

Saudi Arabia · Government integration

Nafath national SSO integration

Let Saudi users sign in to your system with their verified national identity through Nafath — single sign-on built into your own application, owned by you, hosted in-region.

01TL;DR
02The requirement

What Nafath integration actually involves

Nafath gives every resident and citizen a single, government-verified identity they can use to log in to digital services. For a private system that means a user no longer types a name and uploads an ID scan you have to verify by hand — they prove who they are through the Nafath app with a push confirmation, a one-time code, or a biometric step, and your system receives a trusted assertion of that identity.

Technically it is a federated identity flow built on standard OAuth 2.0 / OpenID Connect: your application redirects the user to authenticate, the user confirms in Nafath, and your system receives tokens and verified claims. The work is in doing it correctly — registering as a relying service, handling assurance levels, validating tokens, managing sessions, and degrading gracefully when a user cannot complete the app step.

  • Verified onboarding — confirm a user's national identity at sign-up without manual document review.
  • Single sign-on — one trusted login across your portal, app, or operator-facing surfaces.
  • Assurance levels — request the right level of identity assurance for the action being performed.
  • Audit trail — a record of who authenticated, when, and at what assurance level.
03What we build

A real identity layer inside your application

We build Nafath in as a first-class authentication layer in the system you already run — not a bolted-on login button that leaks edge cases. The handshake, token validation, session management, and fallbacks are written once, tested, and owned by you.

  • OIDC handshake — relying-service registration, the redirect flow, token validation, and verified-claim mapping into your user records.
  • Graceful fallbacks — clear handling when a push times out, a device is unavailable, or a user needs an alternative path, so people are never stranded at the door.
  • Session security — short-lived tokens, refresh handling, and revocation, so a Nafath login is as secure on day 300 as on day 1.
  • In-region hosting — identity logs and session stores in Riyadh or Jeddah, aligned to data-residency expectations.
  • Audit trail — every authentication, assurance level, and failure recorded immutably for security review.
04Why custom

Why integrate Nafath rather than bolt on a generic login

A generic auth widget gives you a login box. It does not give you verified Saudi identity, the right assurance level for a sensitive action, or a clean fallback when the app push fails — and it usually parks your users' identity data with a third party outside the Kingdom. Building Nafath into your own stack keeps the verified claims, the session logic, and the audit trail under your control and in-region.

Identity is also security-critical, so it deserves the same governance as any other production component: validated against the provider's sandbox, versioned, and re-checked when the protocol or assurance model changes. We treat the Nafath layer that way — as software you own and can prove the behaviour of, not a dependency you hope keeps working.

Questions
  • Does Nafath replace our passwords entirely?

    It can. For Saudi residents and citizens, Nafath becomes the trusted way in — verified at sign-up and used for sign-on. We typically keep a secure fallback path for edge cases, all under your control.

  • What identity does our system actually receive?

    Your system receives verified claims about the authenticated user at the requested assurance level, mapped cleanly into your own user records — not a screenshot of an ID to verify by hand.

  • What happens when the Nafath app push fails or times out?

    We build graceful fallbacks — alternative confirmation paths and clear messaging — so a missed push or unavailable device never strands a legitimate user at the door.

  • Is the identity and session data hosted in Saudi Arabia?

    Yes. Identity logs and session stores are hosted in-region (Riyadh/Jeddah) with an immutable audit trail of every authentication and assurance level.

  • Do we own the integration?

    Yes — you receive the source, configuration, and deploy pipeline. The Nafath layer is part of your application, not a rented dependency.

Begin

We don't advise on AI. We run it for you.

Book a consultation

Proven on your data before you commit.