Public wallet login gateway

Never log in again. Use KBeam.

Add KBeam login to your own protected area. KBeam approves the challenge, while your site keeps its sessions, permissions, users, and private routes.

No password is transmitted or stored. KBeam never receives the browser session cookie. Use allowlists, rate limits, HTTPS, and audit logs in production.
No passwords Wallet signature instead of another account form.
No site secrets KBeam never receives your session cookie or poll token.
Self-hostable Review the public gateway and run it for your app.

Transparent by design

The browser gets a private poll token. KBeam gets an approve token and signs a short-lived challenge. Only the waiting browser receives the HttpOnly session for the protected site.

Build it into your own app

Review the protocol, run the tests, choose SQLite or Postgres, enable an allowlist, then put it in front of your own private area. 

{}
Security and trust

KBeam Auth Gateway

KBeam Auth Gateway lets websites and protected areas offer a KBeam unlock instead of another password form. The website creates a one-time login request, the user approves it with KBeam, the gateway verifies the wallet signature, and the website can then create its own secure session.

The security model is based on challenge-response authentication. A login request is short-lived and tied to a specific challenge. No password is transmitted, no password is stored, and no reusable login secret has to be handed to the website. This reduces one of the biggest risks of classic logins: central password databases and reused credentials.

KBeam does not take control of the website. It does not know the protected area, cannot see private pages, and does not manage the user accounts of the application that embeds the gateway. Sessions, roles, permissions, rate limits, audit logs, and access rules remain under the control and responsibility of the website operator.

The gateway is not a magic security shield. Operators still need HTTPS, secure session handling, sensible rate limits, monitoring, wallet policies, and a careful server configuration. What it can do is remove password handling from the login flow and replace it with a verifiable, time-limited KBeam approval.

KBeam unlocks access. The website keeps control.
Vision

The next step is a trusted customer layer

KBeam Auth Gateway starts with one clear purpose: secure login with KBeam, without passwords and without KBeam knowing the protected content of the website that embeds it.

The next stage is intended to build on that foundation with optional user management. A wallet address could be connected to a customer account, while each website still controls its own roles, permissions, data, and protected areas.

A future version is also planned to support optional contact and support flows after login. Users could choose to be reachable for support, direct chat, follow-up questions, or later features such as payments and customer-related actions.

These additions are intentionally not part of the first release. The first step remains a transparent, self-hostable auth gateway. The development direction is to grow it into a base for secure customer accounts, support, and future product workflows.