Skip to main content

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.

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.

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: Any of these, combined with an LLM that knows your codebase, produces a working auth system the same day you start. The deliverable is yours — no per-MAU bill, no vendor lock-in, no AWS dependency.

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?
These are the hard problems. Databunker Pro is built for them:
  • 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 ] ─── sign-in ───► [ Your auth layer (NextAuth / Lucia / Ory / Keycloak / ...) ]

                                       Built once with LLM assistance.
                                       Issues JWT / session.


                                       [ Your application ]


                                       [ Databunker Pro ]
                                       AES-256 encrypted vault
                                       Tokenization · CRBAC · audit
                                       Self-hosted, any region
The application database only ever stores: a user identifier, a Databunker user_token, and any non-PII business data. PII lives in the vault. Auth lives in your own code.

Comparison table

CapabilityAWS CognitoDatabunker Pro + your auth
Primary purposeAuth + user directoryPII vault, tokenization, consent, compliance
Where auth livesManaged AWS serviceIn your codebase (LLM-built, mature library)
Where PII livesCognito user attributes (AWS)Databunker Pro vault (your infra, any cloud)
PII encryptionAWS-managed KMS at the user-pool levelAES-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-erasureAdminDeleteUser (PII in logs/backups still your problem)Single API call; audit-bounded; record-versioning aware
Audit trailCloudTrail (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-boundK8s secret, AWS KMS, HashiCorp Vault, or hardware HSM
Multi-tenancySeparate user poolsNative PostgreSQL RLS
DeploymentAWS onlyAny cloud, on-prem, sovereign region, customer tenant
Data residencyAWS regionsAny region; multi-jurisdiction topology supported
Vendor lock-inAWSNone — Docker / Helm artifacts
Pricing modelPer MAU above the free tierPer-instance license, flat
Future flexibilityConstrained by what AWS adds to CognitoYour 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:
  1. Stand up Databunker Pro in your target environment (Docker / Helm).
  2. 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.
  3. Export the Cognito user list — emails, attributes, group memberships — via ListUsers.
  4. Bulk-import into Databunker Pro using UserCreateBulk — at ~1,700 records/sec on a single instance, a typical Cognito directory imports in minutes.
  5. 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).
  6. Decommission the Cognito user pool once the population has migrated.
For organisations with strict downtime / UX constraints, a dual-running window (Cognito for existing users, new auth + Databunker for new ones, slow migration over weeks) is preferred. Databunker Pro’s bulk import and multi-tenancy support this naturally.

Code examples

Sign-up: auth in your codebase, PII in Databunker

// 1. User signs up via your auth layer (NextAuth / Lucia / Ory / etc.)
//    Your auth issues a session and gives you the verified email.

// 2. Store PII in Databunker — get back a safe UUID token
const response = await axios.post('https://your-databunker/v2/UserCreate', {
  profile: {
    email:   form.email,
    first:   form.firstName,
    last:    form.lastName,
    phone:   form.phone,
    address: form.address,
    dob:     form.dateOfBirth,
  }
}, {
  headers: { 'X-Bunker-Token': process.env.DATABUNKER_API_KEY }
});

const userToken = response.data.token;

// 3. Store only (userId, userToken) in your app DB — zero PII anywhere outside the vault
await db.query(
  'INSERT INTO users (id, databunker_token) VALUES ($1, $2)',
  [authUser.id, userToken]
);
If your application database gets breached, attackers see only opaque UUIDs — no PII, no contact data, no addresses.

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.
curl -X POST https://your-databunker/v2/TokenCreate \
  -H "X-Bunker-Token: YOUR_API_KEY" \
  -d '{
    "record": "4532015112830366",
    "type": "creditcard",
    "expiration": "30d",
    "unique": true
  }'
{
  "status": "ok",
  "tokenuuid": "550e8400-e29b-41d4-a716-446655440000",
  "tokenbase": "4024007186539112"
}
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.

The bottom line

Cognito was the right answer when authentication was a hard build. With LLM-assisted development, auth is an afternoon’s work in your own codebase — and you keep the code, the keys, the deployment, and the data. Pair that with Databunker Pro and you get the secure user storage, tokenization, consent management, audit, and cross-jurisdiction sovereignty that Cognito was never designed to provide. The result: no per-MAU bill, no AWS lock-in, full control over your users’ PII, and a compliance posture that holds up in a regulator review.