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 / OIDC —
client_credentials,device_authorization, token exchange, revocation, JWKS.
Discovery
Start here. The discovery document describes every endpoint, grant type, and supported algorithm BKey offers: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/nodeor 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.
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 aclient_id + client_secret:
- For agents — run
bkey auth setup-agent --savefrom 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):@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
- Authentication overview — all grant types at a glance
- CIBA — biometric approval, with one-line SDK pattern
- Client credentials — agent auth grant
- CLI authentication — human + agent credential flows
- Agent payments — x402 + MPP auto-detection
- Encryption — what’s protected at each step
- API Reference — every endpoint documented