It always starts as a login form. A few months later you're maintaining session storage, token rotation, MFA, social federation, and a list of edge cases that keeps growing. Then there's the part that makes this decision harder in India than almost anywhere else: on top of the usual identity work, you also own DigiLocker, Aadhaar offline e-KYC, DLT-compliant SMS, and a stack of DPDP audit obligations. So what does building actually cost over its lifetime, and when does buying win?

This is a vendor-neutral look at both sides: what "auth" really contains, the India extras you can't skip, the maintenance that never stops, and a simple framework for choosing. No fluff, just the work.

What "auth" really includes

When people say "we will just build auth," they usually picture a username, a password, and a session cookie. The real surface area is much wider. Here is the short version of what a production customer identity stack carries.

Capability	What it actually involves
Standards-correct OAuth/OIDC	Authorization-code flow, discovery document, JWKS, token endpoint, error handling that matches the spec
PKCE everywhere	Proof Key for Code Exchange on every flow, including first-party clients, with no implicit grant
Token signing and rotation	RS256 keys, key rotation, exposing only the public key, refresh-token rotation and replay detection
MFA	TOTP enrollment and verification, recovery codes, passkeys (WebAuthn)
Social federation	Google, GitHub, LinkedIn, each with its own quirks, token formats, and breaking changes
Sessions	Stateless verification plus revocation, device list, logout-everywhere
Rate limiting and abuse	Credential-stuffing defense, OTP-flood protection, lockouts
Audit and account lifecycle	Event history, account deletion, data export

OAuth 2.1 tightens several of these defaults. PKCE is now required for all clients, the implicit grant is gone, and exact redirect-URI matching is expected. You can read the consolidation work at oauth.net. If you build, you own the correct implementation of all of it, including the subtle parts. Refresh-token rotation, for example, is not just "issue a new token." When an old refresh token is presented again, that is a signal of theft, and the correct response is to revoke the entire token chain, not just reject the one request. We cover the spec-level changes in OAuth 2.1 vs 2.0 and the mechanics of PKCE explained.

Passkeys add another layer. WebAuthn moves you off shared secrets entirely, which is a security win, but it means implementing attestation, credential storage, and fallback flows. The FIDO Alliance maintains the specs at fidoalliance.org. None of this is exotic, but all of it is yours to keep correct as browsers and platforms evolve.

The honest summary: "auth" is not a feature, it is a small product. The in-house auth cost is the cost of building and running that product, not the cost of a login screen.

The India extras you cannot skip

Serve Indian users and you inherit a second body of work on top of standard identity. This is where the math diverges sharply from a US-only build. You have to handle rails that simply don't exist anywhere else.

DigiLocker. Government-issued document verification flows through DigiLocker, which uses an OAuth-style consent and pull model via the API Setu platform at apisetu.gov.in. You handle the partner onboarding, the consent screen, the document pull, and the signature checks. We walk through it in the DigiLocker API integration guide.

Aadhaar offline e-KYC. The privacy-respecting path is the offline XML, where the user downloads a signed, password-protected ZIP from UIDAI and you verify the signature locally. UIDAI documents this at uidai.gov.in. The handling rules matter a lot. You should verify the UIDAI signature, store only the minimum (NamoID is built to keep only the last four digits, a name-hash, and the signature-verification result), and never persist the full XML. See Aadhaar offline e-KYC XML verification for the mechanics.

SMS OTP under DLT. You cannot send transactional SMS in India without registering on a TRAI-mandated DLT platform, registering your sender ID and message templates, and sending only approved content. TRAI's framework is described at trai.gov.in. Get the template wrong and your OTPs silently fail to deliver. WhatsApp OTP and Truecaller add alternative rails with their own onboarding. We compare delivery paths in WhatsApp OTP vs SMS OTP in India.

DPDP obligations. The Digital Personal Data Protection Act, 2023, and its Rules add consent, audit, residency, and data-subject-rights requirements that touch your identity layer directly. Every provider connection needs a recorded consent, you need an audit trail of state changes, and you need an export and deletion path. Choosing which rail to ask a user for is itself a design decision, which we lay out in Aadhaar vs DigiLocker vs offline KYC.

None of these India extras are optional if your users are Indian. They are also not one-time builds. Government APIs change, DLT rules tighten, and DPDP Rules continue to phase in. If you build, this is permanent surface area on your roadmap.

Compliance note: this section is general information, not legal advice. Confirm your specific obligations with qualified counsel.

The hidden maintenance cost

The build estimate that gets approved is almost always the cost to ship version one. The cost that actually hurts is everything after. Here is what keeps running once the demo works.

Spec drift. OAuth, OIDC, and WebAuthn evolve. Browser changes break flows. You track and absorb these.
Provider breakage. Google, GitHub, and LinkedIn change token formats, scopes, and consent screens without asking. Each break is an incident.
Government API changes. DigiLocker, UIDAI, and DLT platforms update endpoints, certificates, and template rules. A rotated certificate can take you down at 2am.
Security response. New CVEs in your crypto, JWT, or XML libraries land on your desk. XML signature verification in particular has a long history of parser-level vulnerabilities, so the Aadhaar path needs careful, ongoing attention.
Abuse evolution. Credential stuffing and OTP-flood billing attacks get more sophisticated. Your rate limits and detection need to keep pace.
Audit and residency. DPDP expects an append-only audit trail and the ability to answer data-subject requests. That is a system to keep correct, not a one-off feature.

Two costs are easy to underestimate. The first is on-call. Auth is in the critical path of every login, so an auth outage is a full outage. Someone has to own that pager. The second is opportunity cost. Every engineer-week spent on token rotation or DLT template debugging is a week not spent on your actual product. For most teams, identity is not the differentiator, so the in-house auth cost is largely spent on undifferentiated heavy lifting.

A rough way to think about it: a credible in-house build is not one engineer for a quarter. It is a small ongoing team, because the system never reaches "done." It reaches "running," and running has a recurring price.

When building makes sense

Building is not always the wrong call. There are real cases where owning the stack is the right decision.

Identity is your product. If you are selling authentication, fraud, or KYC as the core offering, you should own the deepest layers. It is your moat.
You have unusual requirements. A flow no vendor supports, a regulated environment with bespoke controls, or an air-gapped deployment can push you to build.
You have the team and the appetite. If you already have security and identity specialists who can carry the on-call and the spec-tracking, the marginal cost of building is lower for you than for most.
You need total control of the trust boundary. Some organizations have policy reasons to keep every key and every line of the verification path in-house.

The honest test is whether you are prepared to staff identity as a long-lived internal product, including its on-call rotation, its security response, and its India-specific maintenance. If yes, building can be the right answer. If the plan is "build it once and move on," that plan does not match how auth actually behaves over time.

When buying makes sense

For most product and platform teams, buying wins because identity is necessary but not differentiating. You want it correct, compliant, and out of your way.

A managed India identity provider collapses the work above into one integration. NamoID is built around a single OIDC issuer URL: you point your app at one discovery document and JWKS endpoint, run the standard authorization-code flow with PKCE, and get back RS256-signed tokens. The same issuer fronts the India rails (DigiLocker, Aadhaar offline XML, WhatsApp OTP, Truecaller, DLT-compliant SMS OTP, email OTP), passkeys, TOTP, and social federation, so you do not stitch together five vendors.

A standard integration looks like ordinary OIDC. Discover the configuration:

curl https://your-issuer.example.com/.well-known/openid-configuration

Then run the authorization-code flow with PKCE, which is the same shape you would use against any compliant provider:

# 1. Redirect the user to authorize, with a PKCE challenge
https://your-issuer.example.com/authorize?response_type=code
  &client_id=YOUR_CLIENT_ID
  &redirect_uri=https://yourapp.example.com/callback
  &scope=openid%20profile%20email
  &code_challenge=BASE64URL_SHA256_OF_VERIFIER
  &code_challenge_method=S256
 
# 2. Exchange the code for tokens, presenting the verifier
curl -X POST https://your-issuer.example.com/token \
  -d grant_type=authorization_code \
  -d code=AUTH_CODE \
  -d redirect_uri=https://yourapp.example.com/callback \
  -d client_id=YOUR_CLIENT_ID \
  -d code_verifier=ORIGINAL_VERIFIER

Because verification is stateless, your backend validates the RS256 signature against the published JWKS without a database call:

{
  "iss": "https://your-issuer.example.com",
  "sub": "user_123",
  "aud": "YOUR_CLIENT_ID",
  "exp": 1750400000,
  "amr": ["pwd", "otp"]
}

Buying also moves the compliance machinery off your plate. NamoID is built so every state change appends to an immutable events table, which gives a DPDP-grade audit trail, and a data-subject-request export endpoint returns a user's full event history plus connected providers. Provider tokens are encrypted at rest with AES-256-GCM, orgs are scoped by org_id, and there is a per-organization data-residency hint, built to keep India data in India. For how that maps to the law, see the DPDP compliance checklist for SaaS and the DPDP audit trail requirements.

If you are weighing this against the usual global vendors, the residency and India-rail gaps are the deciding factor, which we cover in Auth0 alternative for India and AWS Cognito alternative with India data residency.

Compliance note: this is general information, not legal advice. Validate residency and consent design with qualified counsel.

A decision framework

Strip away the emotion and the decision comes down to a few honest questions. Score each one.

Question	Lean build	Lean buy
Is identity your core product?	Yes	No
Do you have dedicated security/identity engineers?	Yes, with on-call	No
Do you need India rails (DigiLocker, Aadhaar, DLT SMS)?	You will own them anyway	Want them solved
How fast do you need to ship?	Time is flexible	Weeks matter
Is DPDP audit, export, and residency already handled?	Yes, in-house	Want it built in
Are unusual or air-gapped requirements involved?	Yes	No

A practical reading: if most of your answers fall in the right column, buy and spend your engineering on the product only you can build. If they fall in the left column, and especially if identity itself is what you sell, building can be justified, as long as you budget for it as a permanent internal product rather than a one-time project.

The trap to avoid is the middle: building a "quick" auth system, treating it as done, and then absorbing years of provider breakage, spec drift, and India-compliance maintenance you never priced in. That is the most expensive path of all, because the cost shows up later, as incidents, instead of upfront, as a line item.

For a deeper look at the category itself, what is CIAM explains why customer identity is a distinct discipline from workforce identity, which is part of why building it well is harder than it looks.

FAQ

Is it cheaper to build or buy authentication in India?

For most teams, buying is cheaper once you count the full lifetime cost. The build estimate usually covers only version one and ignores ongoing maintenance: provider breakage, spec drift, security response, and India-specific work like DLT SMS templates and DigiLocker changes. Building is only cheaper when identity is your core product or you have a dedicated identity team already.

What India-specific work does an in-house auth build add?

On top of standard OAuth and OIDC, you own DigiLocker document verification, Aadhaar offline e-KYC signature checks, TRAI-mandated DLT registration for SMS OTP, optional WhatsApp and Truecaller rails, and DPDP obligations for consent, audit trail, export, and data residency. These are permanent maintenance, not one-time builds.

How long does it take to build auth in-house?

There is no fixed number, and any single estimate is misleading because auth is never "done." Shipping a basic flow is fast, but reaching a correct, secure, compliant, India-ready stack with MFA, passkeys, token rotation, and a DPDP audit trail is a much larger effort, followed by indefinite maintenance.

Can I buy auth and still keep India data in India?

Yes, that is a core reason to buy a local provider. NamoID is built with a per-organization data-residency hint, designed to keep India data in India, and an append-only audit trail plus a data-subject-request export endpoint to support DPDP. Confirm your specific residency obligations with counsel, since this is general information and not legal advice.

Talk to us

If you are weighing build vs buy for an Indian product, we are happy to walk through your specific flows, rails, and residency needs. NamoID is built to give you one OIDC issuer for standard auth, India verification, and DPDP-grade audit in a single integration.

Book a 30-minute demo at calendly.com/polymindslabs/30min, or reach us at hello@namoid.in.