Data Processing Agreement

This Data Processing Agreement ("DPA") forms part of the agreement between Bolrach Technologies Limited, operating the auth.ng identity platform ("auth.ng," "we," "us"), and the developer or business that integrates Login with auth.ng into its own product ("you," the "developer"). It explains how each of us handles personal data when a user signs in to your app through auth.ng.

For the identity claims we pass to your app (name, verification status, phone or email, and similar profile fields a user consents to share), you act as the data controller. You decide why you collect that data, what you do with it inside your product, and how long you keep it once it lands in your systems.

auth.ng acts as a data processor for that same data while it sits on our infrastructure: during sign-up, verification, sign-in, and the moment we hand claims to your app over OpenID Connect. Outside of that flow, when we run the auth.ng platform itself (fraud checks, account security, service analytics), we act as a controller in our own right, and that is covered in our Privacy Policy, not this document.

This DPA covers personal data processed as part of the "Login with auth.ng" integration: account creation, identity verification, authentication, session management, and the claims delivered to your app through our OIDC endpoints or SDKs. It does not cover data you collect through your own forms, analytics tools, or any other part of your product that has nothing to do with auth.ng.

The purpose is narrow on our end: verify that a user is who they say they are, issue a signed token, and hand your app the claims that user agreed to share. We don't process this data for our own marketing, we don't sell it, and we don't use it to build profiles for anyone outside the verification and security purpose it was collected for.

Data subjects are the end users of your app who choose to sign in with auth.ng. They are individuals, and most are based in Nigeria, though the platform is built to serve users anywhere.

Depending on your app's configured scopes, the data we may process and pass through includes:

• Identity fields: full name, date of birth, and a verification status (verified or not).
• Contact details: phone number and/or email address, where a scope requests them.
• A profile photo or avatar, if your app requests it and the user consents.
• Authentication metadata: a stable user identifier (subject/sub), timestamps of sign-in events, and device/session identifiers needed to keep a login secure.
• Technical logs generated during sign-in, such as IP address and browser or app details, kept for fraud prevention and security.

We do not pass raw government ID numbers to your app. auth.ng verifies identity internally and shares only a verification result and the profile fields you've requested. To be clear on timing: NIMC connectivity is not live yet, so no claim on this platform is backed by a NIMC check today. Once that integration ships, this section will be updated and the change will be reflected in the date at the top of this page.

As processor, we commit to the following:

• Process only on instructions. We handle identity data strictly to authenticate your users and deliver the claims your app requested, following the scopes you configured in your developer console.
• Confidentiality. Staff and systems that touch identity data are limited to what their role needs, and everyone with access is bound by confidentiality obligations.
• Security. We apply encryption in transit and at rest, access controls, and monitoring described in Security measures below.
• Sub-processors. We only use the sub-processors listed in Sub-processors, and we'll give notice before adding a new one that materially changes how your users' data is handled.
• Assistance with data-subject requests. If a user asks us to access, correct, or delete their auth.ng account, we'll handle that directly and let you know if it affects an account tied to your app.
• Breach notification. If we become aware of a security incident that affects your users' personal data, we will notify you without undue delay and no later than 72 hours after we confirm it, with what we know at that point and updates as the picture becomes clearer.

As the controller for your users' data once it reaches your app, you agree to:

• Have a lawful basis for collecting and using the data your users share through auth.ng, and say so plainly in your own privacy policy.
• Request only the scopes your app actually needs. Asking for a phone number you never use just adds risk on your side for no benefit.
• Protect the claims once they land in your systems: encrypt what you store, limit who on your team can see it, and don't pass it on to a third party without telling your users.
• Honor revocation. If a user disconnects your app from their auth.ng account or asks you to delete their data, act on it and stop relying on data you no longer have a basis to hold.
• Tell us promptly if you experience a breach involving data received through auth.ng, so we can assess whether it touches our systems too.

If any of this feels unclear for your specific integration, our developer docs and Acceptable Use Policy go into more detail on what's expected of apps built on the platform.

We protect identity data with layered, bank-level security practices, including:

• Encryption in transit (TLS) for every request and encryption at rest for stored identity data.
• Signed, short-lived tokens for authentication, with refresh and revocation built in.
• Role-based access control internally, so only people who need to see identity data for support or security work can.
• Continuous monitoring and logging of access to sensitive systems, with alerting on unusual patterns.
• Regular review of our own security posture as the platform grows, including how sub-processors handle the data we share with them.

No system is unbreakable, and we won't claim ours is. What we commit to is taking security seriously from day one, being honest when something goes wrong, and following the breach notification process above.

We rely on a small number of infrastructure providers to run auth.ng, such as cloud hosting, email or SMS delivery for one-time codes, and error monitoring. Each one is bound by its own data protection terms with us and only processes data for the narrow purpose we use it for (hosting a database, sending an OTP, and so on).

We keep the current sub-processor list available to developers on request through our Privacy Policy and will update it as the platform evolves. Material changes get communicated before they take effect, not buried in a changelog.

auth.ng is built for Nigeria first. Where our infrastructure providers process data outside Nigeria, we require them to meet security and confidentiality standards at least equal to what we commit to in this DPA, and we work to keep Nigerian users' identity data within jurisdictions that offer strong data protection safeguards consistent with the Nigeria Data Protection Act.

If your app or user base is outside Nigeria, we'll work with you directly on any transfer terms your own regulatory environment requires.

We keep records of our processing activities and security practices and can share a summary with developers who need it for their own compliance reviews. For sensitive infrastructure details, we may provide a written attestation rather than raw system access, since letting every developer poke around our production environment isn't realistic at scale. If you have a specific audit requirement, reach out and we'll figure out what we can reasonably provide.

This DPA lasts as long as your app is connected to auth.ng and processing user data through it. If you disconnect your app or close your developer account, we stop passing new claims to you immediately.

Data tied to a user's auth.ng account (as opposed to data already sitting in your own systems) is retained under our Privacy Policy, and deleted or anonymized once it's no longer needed for the purpose it was collected for, subject to any legal retention requirement we're under.

Each party is responsible for its own compliance failures under this DPA and applicable data protection law. auth.ng is liable for how we handle data as processor within the scope described above; you're liable for what you do with claims once they're in your systems, including how your app collects consent, stores data, and responds to your own users' requests. Neither party is responsible for the other's independent processing outside the scope of the Login with auth.ng integration.

Questions about this DPA, a sub-processor list request, or a breach notification should go to [email protected]. auth.ng is a brand of Bolrach Technologies Limited. General support is handled through tickets and our knowledge base rather than a support inbox; see our Terms of Service and Cookie Policy for the rest of the legal picture.