Next.js verification
Use Authbound to add wallet verification to this Next.js App Router app.
Requirements:
- Use @authbound/nextjs.
- Create app/api/authbound/[...authbound]/route.ts with createAuthboundHandlers.
- Keep AUTHBOUND_SECRET_KEY server-only.
- Use NEXT_PUBLIC_AUTHBOUND_PK as the browser-safe publishable key in AuthboundProvider and SDK server handlers; never expose secret keys.
- Use NEXT_PUBLIC_AUTHBOUND_POLICY_ID only in browser code.
- Add a client provider and a verification page using VerificationWall.
- Import @authbound/nextjs/styles.css once in the app layout.
- Do not make final trust decisions from browser status alone.
- Add or update tests for the route handler if this repo has route tests.
React verification UI
Use Authbound to add a React verification UI.
Requirements:
- Use @authbound/react for browser UI.
- Wrap the app in AuthboundProvider.
- Use VerificationWall for the primary flow unless the existing UI needs a custom useVerification implementation.
- Create verifications from a server endpoint, not directly from the browser with a secret key.
- Mount the SDK server router on the same origin so `/api/authbound/verification` and `/api/authbound/session` are available, or set `sessionMode` to `manual` for a custom create-only backend.
- Use the publishable key and clientToken only with browser-safe status and SSE endpoints.
- SDK-managed session finalization must go through the same-origin server route.
- Add loading, verified, failed, canceled, and expired UI states.
Express or Hono backend
Use Authbound to create wallet verifications in this server app.
Requirements:
- Use @authbound/server.
- Keep AUTHBOUND_SECRET_KEY in server environment variables only.
- Prefer createAuthboundRouter for Express or createAuthboundApp for Hono so verification, session, status, webhook, and sign-out routes stay aligned with the browser SDK.
- Keep the default `/api/authbound/session` route for SDK-managed route UX; it must validate the pending browser binding and fetch the signed result server-side.
- Include policyId, customerUserRef when available, and an idempotencyKey for retry-safe creation.
- Return only browser-safe fields to the client: verification id, client token, authorization request URL or client action, status, expiry, and no merchant metadata or customer references.
- Do not log PII, credentials, tokens, or secret keys.
Webhooks and signed results
Add Authbound webhook handling.
Requirements:
- Use verifyWebhookSignatureDetailed from @authbound/server.
- Read the raw request body before parsing JSON.
- Reject missing or invalid x-authbound-signature values.
- Make event handling idempotent using event id or verification id.
- On verified or failed events, fetch or store the server-trusted result.
- Never treat unsigned webhook payloads as trusted.
- Add tests for valid signature, invalid signature, and duplicate delivery.
Route protection
Protect routes with Authbound verification state.
Requirements:
- Keep the verified state in the server session, database, or signed token.
- Redirect unverified users to the verification page.
- Do not rely on client-only React state for protected backend actions.
- Re-check signed verification results or stored verified state before high-trust operations.
- Add tests or route-level verification for verified, unverified, expired, and failed states.
Credential issuance
Use Authbound to issue an OpenID4VCI credential offer.
Requirements:
- Use AuthboundClient from @authbound/server.
- Create or resolve a credential definition for the credential type.
- Map trusted application data into the nested claims object expected by the definition.
- Create an offer with authbound.openId4Vc.issuance.createOffer.
- Use idempotencyKey for retry-safe offer creation.
- Return offerUri or offerQrUri for wallet handoff.
- Keep secrets and unnecessary PII out of credential definition metadata.