Security at NamoID
NamoID is an OAuth 2.1 / OIDC identity provider — the security of your users’ sign-in is the product. This page covers how we protect data, our India/DPDP posture, the assessments we run, and how to report a vulnerability.
How we protect your data
- All traffic is served over TLS. Tokens are RS256-signed and verifiable via our published JWKS — the private signing key never leaves our service.
- PKCE is mandatory on every OAuth flow. There is no implicit flow and no password grant.
- Refresh tokens rotate on every use; a replayed refresh token revokes the entire token chain and raises a security event.
- Connected-provider tokens are encrypted at rest with AES-256-GCM, under a rotatable key. They never appear in logs.
- Every state-changing action writes to an append-only audit log.
- Strict multi-tenant isolation — every query is scoped to your organization.
- Auth and OTP endpoints are rate-limited (Redis-backed) to defend against credential stuffing and OTP-flood abuse.
- Dependencies follow a 7-day publish-age cool-off to blunt supply-chain attacks; CI runs secret-scanning, dependency/CVE audit, and static analysis.
Privacy & data protection (India / DPDP)
NamoID is built compliance-first for India’s DPDP Act 2023. Primary data residency is AWS Mumbai (ap-south-1).
- Aadhaar offline KYC, when used, is masked — we store only the last four digits, a name hash, and the signature-verification result. The full Aadhaar number and the uploaded XML are processed in memory and never persisted.
- Data-subject rights: a complete export of a user’s data and connected providers is available; deletion cascades a soft-delete plus a tombstone record.
- Consent for every provider connection is recorded with timestamp, IP, and scope.
Sub-processors
Every sub-processor that handles personal data runs on Amazon Web Services in the Mumbai (ap-south-1) region.
| Sub-processor | Purpose | Region |
|---|---|---|
| Amazon Web Services | Compute, database, and cache (EC2, PostgreSQL, Redis) | ap-south-1 |
| Amazon SES | Transactional email (OTP, verification, password reset) | ap-south-1 |
| Amazon End User Messaging | SMS OTP delivery | ap-south-1 |
Assessments & compliance
We run internal security assessments by the PolyMindsLabs security team (the team behind NamoID) against an OAuth/OIDC-specific test plan, and publish a summary of each. To be clear about provenance: these are first-party assessments.
NamoID has not yet completed an independent third-party penetration test or a SOC 2 / ISO 27001 certification. We pursue independent certification as customer requirements call for it. A detailed threat model and full assessment results are available under NDA.
Reporting a vulnerability
Email security@namoid.in (falls back to hello@namoid.in). We acknowledge within 48 hours and triage within 5 business days.
Include a clear description, reproduction steps, impact assessment, and (optional) a suggested fix.
Fix-time targets
| Severity | Target fix time |
|---|---|
| Critical (auth bypass, RCE, token leak) | 7 days |
| High (privilege escalation, PII exposure) | 30 days |
| Medium (CSRF, info disclosure) | 60 days |
| Low / informational | Best effort |
Safe harbor
If you act in good faith (no data exfiltration beyond proof-of-concept, no service disruption, no targeting of other customers' accounts, and you give us time to fix before disclosing), we won't pursue legal action.
- Testing your own NamoID test-mode accounts is fine.
- Reasonable rate-limit probing is fine.
Not covered
- Phishing or social engineering of NamoID staff or customers.
- Attacks against other customers' production environments or their end-users.
- Persistent denial-of-service.
- Exfiltrating more PII than the minimum needed to demonstrate the issue.
- Public disclosure before a fix ships or 90 days have passed since acknowledgement.
Out of scope
- Missing security headers on marketing pages with no user state.
- Self-XSS or clickjacking without a working account-takeover PoC.
- Automated-scanner output with no proof of exploitability.
- Vulnerabilities in dependencies that don't affect our usage.
- Email spoofing on domains we don't own.
Hall of fame
No reports acknowledged publicly yet. Be the first.