Sign-in your users already trust, built into your app

Nafath is the national digital identity service that people in the Kingdom use to confirm who they are, usually by approving a request in the Nafath app on their phone. When your product integrates with it, the user proves their identity through that familiar step instead of creating yet another password. Your system receives the result and decides what to do with it.

Two things are easy to confuse. The first is the integration, which is software: screens, API calls, session handling, error cases and logs. That is what we build. The second is access, which is an administrative matter: each platform decides who may connect, on what terms and with which documents. That comes from the platform's own onboarding and your own company registration. We do not hold access on your behalf, and we do not claim any relationship with a government body.

The practical consequence is simple. Start the onboarding conversation early, because it often sets the timeline. We can build and test the surrounding product while that runs, then connect the live details once your access is in place.

A sign-in that works in a demo can still fail in the field. Phones are offline, approvals time out, users open the wrong app, and some people share a device. We design for these cases first. Every state has a message in Arabic and English, a retry rule and an owner on your side who sees repeated failures.

The second decision is identity matching. When a verified person signs in, which record in your system is theirs? For existing customers you may match on a national ID or iqama number you already hold. For new users you create a record. Mismatches need a human path, and that path should be built, not improvised. We also decide what you store. Keep only what the product needs, and treat identity data as personal data under the Personal Data Protection Law, with defined retention and access.

Sessions deserve care too. A verified sign-in should not live forever. We design short sessions, a refresh rule, and step-up verification for actions such as changing a bank account or signing a contract. The OAuth 2.0 and OpenID Connect specifications describe patterns that suit this work, and we apply them where the platform's own method allows.

Teams often ask for Nafath, Absher and Tawakkalna in one sentence, but they are different platforms with different purposes and different rules for connecting. Some offer service-to-service APIs to registered organizations. Others are citizen-facing apps that your product may link to or open from a button, with no data exchange. The right design depends on which of these applies to your use case.

We start with a short discovery: what you want the user to do, which platform serves that need, and what that platform currently offers to a business like yours. Where an integration path exists, we build against its published documentation and test in whatever sandbox it provides. Where none exists, we say so plainly and design a clean handoff, such as a deep link or an upload step, rather than a workaround that could breach the platform's terms.

Because platform rules change, we write the integration so each external call sits behind one adapter. If a platform updates its method, the change is made in one place and your product keeps running. We also document who owns each credential on your side, because a lapsed registration is a common cause of outages. Hosting can be set up inside the Kingdom when your policy or sector rules call for it.