User Security

• At creation, the raw key is shown once and never stored. Only a SHA-256 hash is persisted.
• The key prefix (first 8 characters) is stored for identification in logs and the dashboard.
• At the edge, the Cloudflare Worker authenticates the key via KV lookup, verifies the hash, and strips the raw key from the request before forwarding to the application backend.
• Internal requests carry signed context such as the developer ID, key ID, tier, and org scope.

If a key is compromised, revoke it immediately from the dashboard. A new key can be created in seconds.

Yes. oakallow is a security platform, so passkey-based MFA is required on every account. There is no opt-out.

• You sign in with a passkey, or with an email one-time code if you have not enrolled a passkey yet
• On your first sign-in you are sent to the Security page and asked to enroll a passkey before anything else is unlocked
• 10 single-use recovery codes are generated automatically the first time you enroll a passkey. Save them somewhere safe.
• From then on, every sign-in uses your passkey (Face ID, Touch ID, Windows Hello, fingerprint, or a hardware security key)
• You can add multiple passkeys for different devices, rename them, or remove them from the Security page any time

• Passkeys are phishing-resistant by design. A fake oakallow page cannot use them.
• No six-digit codes to type, lose, or intercept
• Works identically across iOS, Android, macOS, Windows, and hardware keys
• Syncs through your device ecosystem (iCloud Keychain, Google Password Manager, 1Password, etc.) so a lost phone is rarely catastrophic

A note on cross-platform sync. Passkeys created in Apple devices stay in iCloud Keychain. Passkeys created in Google or Chrome stay in Google Password Manager. The two ecosystems do not sync to each other. If you create a passkey on an iPhone and then try to sign in on an Android phone, sign-in still works through WebAuthn cross-device flow (your Android shows a QR code that you scan with the iPhone), but for daily convenience we recommend enrolling at least one passkey per device family.

If you lose access to every enrolled passkey, see the "What if I lose my passkey?" question below.

Recovery codes are your backup if you lose access to every enrolled passkey. They are single-use, 26-character codes generated automatically the first time you enroll a passkey on your account. Each account gets 10 codes.

• Once, automatically, when you enroll your first passkey
• The plaintext is shown to you exactly once. After that we only store a SHA-256 hash, so we cannot show them to you again.
• You can regenerate a fresh batch of 10 from the Security page on the web at any time. Regenerating invalidates every previous code.

• On the Security page, click "Use a recovery code" and enter one
• On success, all of your existing passkeys are invalidated and the code is consumed
• You are signed in temporarily and required to enroll a new passkey before you can do anything else
• The remaining codes still work, but you are down by one

• A password manager like 1Password, Bitwarden, or Apple Passwords is the most convenient option
• Printed and locked in a safe is fine too
• Do not save them in plain-text files or screenshots on the same device as your passkey. If you lose that device you lose both at once.

If you run out of recovery codes and have lost access to every passkey, contact support@oakallow.io from the email on your account and we will verify ownership and reset your passkey requirement.

You have three recovery paths in order of speed.

Fastest: redeem a recovery code.

• If you saved your 10 recovery codes when you first enrolled a passkey, you can use one to recover
• On the sign-in page, click "Use a recovery code" instead of signing in with a passkey
• Enter your email and one of the codes. On success, all existing passkeys are invalidated and you are required to enroll a new passkey immediately.
• See the recovery codes question above for details

• Apple. Passkeys stored in iCloud Keychain sync to every device signed into the same Apple ID. If you still have a Mac, iPad, or another iPhone signed in, try signing into oakallow there. The passkey will be available.
• Google. Passkeys in Google Password Manager sync across Chrome on any device signed into the same Google account.
• 1Password, Bitwarden, Dashlane. Passkeys stored in your password manager are available everywhere that manager is installed and unlocked.
• Hardware keys (YubiKey, Titan). Not synced. If the key is lost, use a recovery code or contact support.

If you have access from another device, sign in with that one, then go to the Security page and remove the lost passkey. Add a new passkey on your replacement device from the same page.

Last resort: contact support.

• If you cannot access any enrolled passkey and have no recovery codes left, email support@oakallow.io from the address on your oakallow account
• Include your account email and a brief description of what happened (lost device, wiped phone, hardware key lost, etc.)
• We will verify ownership and reset the passkey requirement so you can sign in with email OTP and enroll a new passkey
• Turnaround is typically under one business day

To make future recovery easier, we strongly recommend enrolling at least two passkeys (for example one on your phone and one on your laptop, or one in a password manager and one on a hardware key) and keeping your recovery codes in a separate location from your devices. You can add additional passkeys any time from the Security page.

Permission resolution happens at the edge in a Cloudflare Worker.

Permission rules are stored in Cloudflare D1, so when a permission check request arrives, the Worker can resolve it locally without making a round-trip to a separate backend. This delivers very fast decisions and keeps the policy path close to the request path.

The Cloudflare Worker owns the auth and permission surface, while the dashboard and management APIs use the same D1-backed data model, so rule changes stay in sync across the product.

• Cloudflare Workers handle authentication, API key verification, permission resolution, token minting, approvals, execution logging, billing, team management, support workflows, and the developer dashboard API.

• Cloudflare Pages serves the developer dashboard, documentation, and marketing site.

• Cloudflare D1 is the shared relational data store for permission and runtime data, and Cloudflare KV is used for fast key lookups, auth caching, and OAuth 2.1 grant storage.

• Cloudflare R2 stores support attachments.

User authentication is native. Passkeys (WebAuthn) and email one-time codes are issued, verified, and stored by oakallow itself, not by a third-party identity provider. Recovery codes are SHA-256 hashed and stored in our database.

The MCP connector (which integrates oakallow with Claude and ChatGPT) is also fully self-hosted. We run our own OAuth 2.1 authorization server on api.oakallow.io using the open-source @cloudflare/workers-oauth-provider library, with PKCE S256 required, refresh-token rotation, dynamic client registration, and a consent screen on our own domain. Compliance details are on our /docs/oauth page.

Supporting services such as Stripe (web billing), Apple StoreKit and Google Play Billing (mobile in-app purchases), Apple Push Notification Service and Firebase Cloud Messaging (mobile push), and Resend (transactional email) plug into that core architecture.

Internal service communication uses signed headers with a 30-second drift window for timing-safe validation where applicable.

The oakallow MCP connector at api.oakallow.io/mcp implements OAuth 2.1 BCP and the MCP Authorization Specification (2025-03-26). PKCE with S256 is required on every authorization, the implicit flow and resource-owner password grant are not accepted, refresh tokens rotate on every use, redirect URIs are exact-matched, and every authorization, token issuance, and revocation is recorded in our audit log.

The full endpoint table, scope descriptions, supported flows, token lifetimes, revocation paths, and per-claim compliance evidence are documented at oakallow.io/docs/oauth. That page is the canonical reference we share with AI-platform review teams when submitting connector listings.