Skip to main content

Integrate BKey as your authorization layer

You do not need our SDK to use BKey. We’re a standards-compliant OAuth 2.1 / OIDC / CIBA (RFC 8958) provider — any auth library that speaks those protocols can talk to BKey directly. Use BKey when you want any of the following in your own app or server:
  • Per-action biometric approval — CIBA: push a consent prompt to a user’s phone, get back a signed JWT proving they approved the specific action.
  • Agent payments — x402 (USDC on Base, via EIP-3009) and MPP (Stripe Shared Payment Tokens). Your 402-serving code calls BKey’s authorize endpoints; BKey handles spending limits, biometric approval, and signing.
  • Standard OAuth 2.1 / OIDCclient_credentials, device_authorization, token exchange, revocation, JWKS.

Discovery

Start here. The discovery document describes every endpoint, grant type, and supported algorithm BKey offers:
Most OIDC libraries auto-configure from this URL. See the OIDC discovery endpoint reference.

Endpoints

Standard OAuth 2.1 / OIDC

Per-action biometric approval (CIBA)

Your app calls /oauth/bc-authorize with a login_hint (the user’s DID), a scope, and a human-readable binding_message. The user gets a push notification, approves with biometrics, and your app’s poll returns an EdDSA-signed JWT scoped to that specific action. Typical integration shapes:
  • MCP servers — gate every tool call on CIBA; verify the returned token with @bkey/node or any JWKS-aware JWT library. See MCP integration.
  • Admin consoles / deploy pipelines — require a fresh biometric approval before destructive operations (deploy, rollback, db drop, refund).
  • Any app with a “confirm with your phone” pattern — replace the soft click with a cryptographically bound, replay-resistant attestation.
See the CIBA guide for the full protocol and the one-line SDK pattern.

Agent payments (x402 + MPP)

For agents and 402-serving APIs. BKey handles spending limits, biometric approval (via CIBA above), and payment signing — your agent or server never touches the user’s keys. Auto-detection is built in — the CLI proxy, skill, and SDK inspect the 402 response headers and pick the right protocol. If you’re building a gateway or SDK of your own, you can call these endpoints directly. See the agent payments guide for the auto-detect flow and cost comparison.

Vault (E2EE secrets)

Vault values are end-to-end encrypted between your process and the user’s phone. The server never sees plaintext. See encryption for the full envelope (X25519 ECDH + AES-256-GCM).

Checkout

Registering your app / agent

Before you can hit most of these endpoints, you need a client_id + client_secret:
  • For agents — run bkey auth setup-agent --save from a logged-in CLI. BKey pushes a one-time approval to your phone for the scopes you want, then issues the credentials. Details in CLI authentication.
  • For apps that act as an OIDC client on behalf of other users — reach out; we’ll provision a client for you.

Token format

All tokens BKey issues are JWTs signed with EdDSA (Ed25519):
Verify with any JWKS-aware JWT library or @bkey/node’s verifyToken(). The library pins alg: EdDSA, enforces scope, and returns null-prototype claims. No HS256 confusion, no alg: none.

Integration patterns

See also