Wenme is KaritKarma's 100% passwordless identity platform. It is an OAuth 2.1 and OpenID Connect authorization server with WebAuthn/FIDO2 passkeys, cross-device QR sign-in, TOTP authenticator support, and single-use magic links, plus enterprise federation through SAML 2.0 IdP, LDAP/Active Directory sync, and SCIM 2.0 provisioning. It is delivered as a Go identity service exposing 305 API routes, backed by PostgreSQL 18 and Redis 8, with a multi-tenant admin console. There is no password database, by design, and it is live at wenme.net.

Does Wenme support multi-factor authentication for regulated institutions?

Yes. Wenme's default enrollment is a WebAuthn passkey as the primary factor with TOTP as the backup factor, and per-app passkey policies let each application set its own enrollment rules. TOTP secrets are encrypted at rest, login attempts are rate limited through distributed Redis counters, and a risk engine scores device and context factors on every login. Every authentication event lands in the security event log with origin, device, and outcome.

How does WebAuthn handle phishing?

WebAuthn assertions are origin-bound by cryptographic construction. The private key signs a challenge that includes the relying-party ID (the verified origin), and the browser refuses to use a key registered for one origin against another. An attacker on a phishing domain cannot trick the device into producing a valid assertion for the real domain, even with a perfect visual clone of the login page. There is no shared secret to steal, no OTP to relay, and no password to type into a fake form.

How is Wenme different from Auth0, Okta, or Keycloak?

Wenme is 100% passwordless with no password database at all. Auth0, Okta, and Keycloak all retain password authentication as a first-class factor. Wenme mandates PKCE (S256 only) on every flow, disables the OAuth implicit grant entirely, and ships the modern extension set (PAR, CIBA, DPoP, JARM, mTLS) plus SAML 2.0 IdP, LDAP/AD sync, and SCIM 2.0 in the core service rather than as add-ons. It also ships cross-device QR sign-in in the WhatsApp Web pattern. Pricing is in BDT and contracts execute under Bangladesh law.

Can Wenme run on-premises or only as a hosted service?

Both. Wenme runs hosted at identity.wenme.net for tenants who want zero infrastructure. For banks and regulated institutions that require in-house deployment, Wenme ships as a Docker Compose stack deployable inside the customer data centre, in-region on APNIC AS 64005. Both modes run the same codebase and the same 67-migration schema.

What protocols and standards does Wenme implement?

OAuth 2.1 (authorization code with mandatory PKCE S256), OpenID Connect Core with discovery, userinfo, JWKS, token introspection and revocation, Pushed Authorization Requests (RFC 9126), CIBA backchannel authentication, DPoP proof-of-possession tokens (RFC 9449), JARM secured responses, mutual TLS, WebAuthn Level 3 / FIDO2 passkeys, SAML 2.0 IdP, LDAP/Active Directory sync (RFC 4511), SCIM 2.0 provisioning (RFC 7644), and TOTP (RFC 6238). ID and access tokens are signed with EdDSA (Ed25519) with key rotation infrastructure.

The password is the breach vector. We deleted it.

Name: Wenme
Brand: KaritKarma

Wenme is 100% passwordless identity for Bangladesh's regulated institutions. OAuth 2.1 with mandatory PKCE, WebAuthn/FIDO2 passkeys, cross-device QR sign-in, SAML 2.0 IdP, LDAP/AD sync, SCIM 2.0. 305 API routes, EdDSA-signed tokens. Live at wenme.net.

Book a technical briefing Visit wenme.net

Passwords stored

ever, by design

305

API routes

one Go identity service

DB migrations

schema, fully versioned

S256

PKCE, mandatory

no implicit flow

POST /authorize

POST /oauth/authorize
  ?response_type=code
  &client_id=boooks
  &code_challenge=E9Melhoa2...S256
  &code_challenge_method=S256

<-- 200 OK
{
  "challenge": "webauthn-auth-7f3a...",
  "rpId": "wenme.net",
  "allowCredentials": [{
    "type": "public-key",
    "id": "k5O...c3Jz"
  }]
}

POST /oauth/token
  { "assertion": "o2NmbXkr..." }

<-- 200 OK
{
  "access_token": "eyJhbGciOiJFZERTQS...",
  "token_type": "DPoP",
  "expires_in": 1800,
  "amr": ["user", "hwk", "uvk"]
}

Authentication

Four factors. One credential model. Zero passwords.

Passkey is primary. QR is the cross-device path. TOTP is backup. Magic link is the on-ramp. No password factor exists anywhere in the system.

WebAuthn passkey

FIDO2 passkeys backed by Touch ID, Face ID, Windows Hello, or hardware keys (YubiKey, Titan). Private key never leaves the device. Phishing-resistant by construction.

Cross-device QR

WhatsApp Web style: scan a one-time QR on desktop, approve with Face ID on phone, desktop session opens. No password typed on a public terminal.

TOTP authenticator

Google Authenticator, Authy, 1Password (RFC 6238). 30-second window, per-attempt rate limiting. The backup factor when a passkey device is unavailable.

Magic link

Single-use email links: platform login links expire in 1 hour, invite and MFA tokens in 5 minutes. The on-ramp to passkey enrollment, not a long-lived credential.

Protocol coverage

Every protocol your auditor will ask about. Native.

Not "available as an add-on" or "varies by tier." These ship in the core service, on every tenant.

Protocol	Spec	Use case	Capability
OAuth 2.1	draft-ietf-oauth-v2-1	Web and mobile SSO	Authorization code only, mandatory PKCE (S256), no implicit flow
OpenID Connect	OIDC Core 1.0	Identity on OAuth 2.1	Discovery, userinfo, JWKS, EdDSA (Ed25519) signed tokens
PAR	RFC 9126	High-assurance clients	Pushed authorization requests, parameters posted server-side
CIBA	OpenID CIBA Core	Decoupled authentication	Client-initiated backchannel authentication
DPoP	RFC 9449	Token theft resistance	Proof-of-possession access tokens with ES256 proofs
JARM + mTLS	OpenID JARM, mutual TLS	Bank-grade hardening	JWT-secured authorization responses, mutual-TLS
WebAuthn / FIDO2	WebAuthn L3, CTAP 2.1	Passkey + hardware MFA	Resident keys, attestation, user verification
SAML 2.0 IdP	OASIS 2005	Legacy enterprise federation	SSO redirect + POST bindings, signed assertions
LDAP / AD	RFC 4511	Directory sync + bind	Group-to-role mapping, scheduled sync
SCIM 2.0	RFC 7644	Automated provisioning	Users + Groups endpoints with filtering
TOTP	RFC 6238	Backup MFA factor	30-second window, distributed rate limiting

How it works

How a passkey login actually works.

1
Enroll the passkey
User signs in once with a single-use magic link. Wenme prompts WebAuthn registration; the device generates a key pair in the secure enclave and returns the attestation. Wenme stores only the public key plus credential ID.
2
Re-auth with passkey
On every subsequent login, the app calls /authorize with PKCE. Wenme returns a WebAuthn challenge bound to the credential ID. The device unlocks (Touch ID, Face ID, Windows Hello, YubiKey) and returns a signed assertion.
3
Verify + issue token
Wenme verifies the assertion signature, origin, RP ID, and counter, then issues a short-lived EdDSA-signed OAuth 2.1 access token carrying the passkey AMR claim.
4
Audit + revoke
Every authentication event lands in the SIEM-ready audit log with device attestation, origin, IP, and outcome. Lost devices are revoked from the user profile in one click; outstanding sessions terminate within the access-token TTL.

Regulatory controls

Designed for the controls regulators ask about.

Phishing-resistant MFA by default

WebAuthn passkey as primary factor with TOTP backup and per-app passkey policies. The control area BB CSF v1.0 cares about most.

webauthn.go + totp.go

Session discipline + risk scoring

Sessions expire after 30 minutes idle and 7 days absolute, on Redis-backed storage. A login risk engine scores device and context on every authentication.

30 min / 7 day

Security event logging

Every authentication event recorded with origin, device, and outcome. Saved audit queries for recurring reviews. Evidence your auditors can pull on demand.

security_events

No extractable credentials

User credentials are device-resident asymmetric keys, never extractable from a database breach. Sensitive fields encrypted at rest with AES-256-GCM. Tokens are EdDSA-signed.

AES-256-GCM + EdDSA

Comparison

Wenme vs. Auth0, Okta, Keycloak.

Capability	Auth0	Okta	Keycloak
100% passwordless (no password DB at all)
OAuth 2.1 with mandatory PKCE (no implicit flow)	PKCE optional	PKCE optional	PKCE optional
WebAuthn passkeys + cross-device QR	Passkeys only	Passkeys only	Passkeys only
PAR, CIBA, DPoP, JARM, mTLS in the core	Varies by tier	Varies by SKU	Varies by version
SAML 2.0 IdP + LDAP/AD sync + SCIM 2.0	Enterprise add-ons	Separate SKUs	Included, self-host
Pricing in BDT, contracts under Bangladesh law			Self-host only

Stack

Go, Postgres, Redis. No magic.

Identity service

Go 1.26.4, Gin 1.12.0, EdDSA (Ed25519) signing

Frontend

Next.js 16.2, React 19.2, TypeScript 6, Tailwind CSS 4

Data

PostgreSQL 18, Redis 8, MinIO (S3-compatible)

Hardening

Redis rate limiting, CSRF, Turnstile, AES-256-GCM at rest

Operations

Prometheus metrics, webhooks, GDPR export + deletion

Frequently asked

Questions banks, NBFIs, and MFSPs ask first.

What is Wenme?: Wenme is KaritKarma's 100% passwordless identity platform. It is an OAuth 2.1 and OpenID Connect authorization server with WebAuthn/FIDO2 passkeys, cross-device QR sign-in, TOTP authenticator support, and single-use magic links, plus enterprise federation through SAML 2.0 IdP, LDAP/Active Directory sync, and SCIM 2.0 provisioning. It is delivered as a Go identity service exposing 305 API routes, backed by PostgreSQL 18 and Redis 8, with a multi-tenant admin console. There is no password database, by design, and it is live at wenme.net.
Does Wenme support multi-factor authentication for regulated institutions?: Yes. Wenme's default enrollment is a WebAuthn passkey as the primary factor with TOTP as the backup factor, and per-app passkey policies let each application set its own enrollment rules. TOTP secrets are encrypted at rest, login attempts are rate limited through distributed Redis counters, and a risk engine scores device and context factors on every login. Every authentication event lands in the security event log with origin, device, and outcome.
How does WebAuthn handle phishing?: WebAuthn assertions are origin-bound by cryptographic construction. The private key signs a challenge that includes the relying-party ID (the verified origin), and the browser refuses to use a key registered for one origin against another. An attacker on a phishing domain cannot trick the device into producing a valid assertion for the real domain, even with a perfect visual clone of the login page. There is no shared secret to steal, no OTP to relay, and no password to type into a fake form.
How is Wenme different from Auth0, Okta, or Keycloak?: Wenme is 100% passwordless with no password database at all. Auth0, Okta, and Keycloak all retain password authentication as a first-class factor. Wenme mandates PKCE (S256 only) on every flow, disables the OAuth implicit grant entirely, and ships the modern extension set (PAR, CIBA, DPoP, JARM, mTLS) plus SAML 2.0 IdP, LDAP/AD sync, and SCIM 2.0 in the core service rather than as add-ons. It also ships cross-device QR sign-in in the WhatsApp Web pattern. Pricing is in BDT and contracts execute under Bangladesh law.
Can Wenme run on-premises or only as a hosted service?: Both. Wenme runs hosted at identity.wenme.net for tenants who want zero infrastructure. For banks and regulated institutions that require in-house deployment, Wenme ships as a Docker Compose stack deployable inside the customer data centre, in-region on APNIC AS 64005. Both modes run the same codebase and the same 67-migration schema.
What protocols and standards does Wenme implement?: OAuth 2.1 (authorization code with mandatory PKCE S256), OpenID Connect Core with discovery, userinfo, JWKS, token introspection and revocation, Pushed Authorization Requests (RFC 9126), CIBA backchannel authentication, DPoP proof-of-possession tokens (RFC 9449), JARM secured responses, mutual TLS, WebAuthn Level 3 / FIDO2 passkeys, SAML 2.0 IdP, LDAP/Active Directory sync (RFC 4511), SCIM 2.0 provisioning (RFC 7644), and TOTP (RFC 6238). ID and access tokens are signed with EdDSA (Ed25519) with key rotation infrastructure.

Stop hashing passwords. Start signing assertions.

A 45-minute session with the engineer who will be responsible for your deployment. We map your audit findings to specific platform controls.