AWS Cognito was built in 2014, when standing up authentication — sign-in, password reset, OAuth, SSO federation, JWT issuance — was genuinely a multi-month project. That world is gone. With LLM-assisted development and modern auth libraries, the auth layer is now an afternoon’s work. What’s actually hard in 2026 is the part Cognito doesn’t solve: encrypting PII at rest, tokenising sensitive fields, tracking consent, handling DSARs, proving compliance to an auditor, and meeting cross-border data-localisation laws. Databunker Pro + LLM-built auth is the modern replacement for Cognito. You build the auth glue once, in your own codebase, with full control. Databunker Pro handles everything Cognito can’t: the PII vault, format-preserving tokenization, consent management, audit, and compliance — self-hosted in any cloud, on-premises, or across jurisdictions.Documentation Index
Fetch the complete documentation index at: https://docs.databunker.org/llms.txt
Use this file to discover all available pages before exploring further.
Authentication is now an afternoon, not a project
LLMs (Claude, Cursor, Copilot, GitHub Codespaces) scaffold a complete auth system from a single prompt: email/password sign-up, Google / Microsoft / Apple SSO, JWT sessions with refresh, password reset, MFA via TOTP or magic links, account recovery. Pair that with a well-maintained library and you have a production-ready auth layer in hours, not months. A non-exhaustive list of mature, well-documented auth libraries that pair cleanly with LLM-driven implementation:| Stack | Library |
|---|---|
| Node / Next.js | NextAuth.js / Auth.js, Lucia, Passport.js |
| Python | Authlib, FastAPI Users |
| Go | Ory Kratos, GoTrue |
| Multi-language | Keycloak, Ory, Authelia |
What auth doesn’t solve — and Databunker Pro does
The auth layer issues identity tokens. It does not answer:- Where do you store your users’ PII so it isn’t exposed in logs, backups, or a SQL injection?
- How do you tokenise credit-card numbers to shrink PCI scope?
- How do you fulfil a GDPR / DPDPA right-to-erasure request across every system that holds the user’s data?
- How do you prove to an auditor that every PII access was authorised and logged?
- How do you keep Indian users’ PII in India, Russian users’ PII in Russia, and EU users’ PII in the EU — all simultaneously?
- PII Vault — AES-256 per-record encryption; the application stores only UUID tokens, never PII.
- Format-preserving tokenization — Luhn-valid credit-card tokens, integer tokens, timestamp tokens. Real PCI-scope reduction.
- Consent management — legal-basis tracking, user agreements, processing-activity records aligned with GDPR / DPDPA.
- DPO operations — DSAR fulfilment, right-to-erasure, data-portability via the separate Databunker DPO product.
- Audit trail — per-record, per-field, with encrypted PII context. See Access control.
- Multi-tenancy — PostgreSQL row-level security; cryptographic per-domain isolation.
- Record versioning — immutable history for every user record.
- Fuzzy search — typo-tolerant search on encrypted data.
- Shared records — time-limited UUID references for safe cross-system sharing.
- Shamir secret sharing — master-key recovery split across multiple custodians.
- BYOK / HYOK — wrapping key in Kubernetes secret, AWS KMS, HashiCorp Vault, or hardware HSM.
- Multi-jurisdiction deployment — one vault per jurisdiction (India, Russia, Turkey, EU, etc.) — a topology Cognito cannot match because Cognito is AWS-bound.
- Self-hosted — deploy on any cloud, on-premises, in a sovereign region, or inside a customer’s tenant.
- Predictable pricing — per-instance license, flat regardless of user count. No per-MAU bill.
Reference architecture
user_token, and any non-PII business data. PII lives in the vault. Auth lives in your own code.
Comparison table
| Capability | AWS Cognito | Databunker Pro + your auth |
|---|---|---|
| Primary purpose | Auth + user directory | PII vault, tokenization, consent, compliance |
| Where auth lives | Managed AWS service | In your codebase (LLM-built, mature library) |
| Where PII lives | Cognito user attributes (AWS) | Databunker Pro vault (your infra, any cloud) |
| PII encryption | AWS-managed KMS at the user-pool level | AES-256 per record, FIPS 140-2, customer-controlled keys |
| Tokenization (UUID + format-preserving) | ❌ | ✅ Native; shrinks PCI scope |
| Consent management & legal basis | ❌ | ✅ Native (GDPR / DPDPA aligned) |
| Right-to-erasure | AdminDeleteUser (PII in logs/backups still your problem) | Single API call; audit-bounded; record-versioning aware |
| Audit trail | CloudTrail (API-level) | Per-record, per-field, with encrypted PII context |
| Fuzzy search on encrypted data | ❌ | ✅ |
| Record versioning | ❌ | ✅ |
| Customer-held keys (BYOK / HYOK) | KMS CMK option, AWS-bound | K8s secret, AWS KMS, HashiCorp Vault, or hardware HSM |
| Multi-tenancy | Separate user pools | Native PostgreSQL RLS |
| Deployment | AWS only | Any cloud, on-prem, sovereign region, customer tenant |
| Data residency | AWS regions | Any region; multi-jurisdiction topology supported |
| Vendor lock-in | AWS | None — Docker / Helm artifacts |
| Pricing model | Per MAU above the free tier | Per-instance license, flat |
| Future flexibility | Constrained by what AWS adds to Cognito | Your codebase — change auth library, add MFA mode, swap SSO provider any time |
Migration from Cognito
The honest practical answer: Cognito does not allow exporting password hashes, so a migration is necessarily a forced-reset event. The standard playbook:- Stand up Databunker Pro in your target environment (Docker / Helm).
- Build the replacement auth layer in your codebase using an LLM and the library of your choice (NextAuth, Lucia, Ory, Keycloak, etc.). Wire it to Databunker Pro for the user record.
- Export the Cognito user list — emails, attributes, group memberships — via
ListUsers. - Bulk-import into Databunker Pro using
UserCreateBulk— at ~1,700 records/sec on a single instance, a typical Cognito directory imports in minutes. - Migration window: switch the auth layer to your replacement and force a one-time password reset email to every user (unavoidable — Cognito does not expose hashes).
- Decommission the Cognito user pool once the population has migrated.
Code examples
Sign-up: auth in your codebase, PII in Databunker
Format-preserving credit-card tokenization
Cognito has no concept of this. Databunker Pro tokenises a real card number into a Luhn-valid token that passes format validation in downstream systems — so legacy fraud / payment / risk systems keep working without ever seeing the real card.tokenbase passes Luhn checks and 16-digit format validation, but maps to no real card. PCI audit scope shrinks to the systems that genuinely need detokenisation.