oakallow sits between your AI agent and your tools, so it has to be trustworthy from the first sign-in. Here's how we handle identity, keys, and account recovery.
Our approach in one sentence
Authentication is native. Passkeys, one-time codes, and recovery codes are issued, verified, and stored by oakallow itself. There is no third-party identity provider sitting in the path between you and your account.
The four pillars
Passkeys, not passwords
Sign-in uses a passkey on every account. Face ID, Touch ID, Windows Hello, a fingerprint, or a hardware security key. Whatever your device already supports. Passkeys are phishing-resistant by design, so a fake sign-in page can't capture them. No passwords to type, leak, or reuse.
Multi-factor authentication is on by default for every account. New users sign in with a one-time email code, then enroll a passkey before they reach any sensitive page. There's no opt-out, and we treat the passkey itself as the second factor. No separate authenticator app to install.
Ten single-use recovery codes are generated the first time you enroll a passkey. We show them once; after that we only store a hash, so we couldn't share them back even if you asked. Lose every device and you can sign back in with one code and enroll a new passkey. No support ticket required.
When you create an API key, the full value is shown to you exactly once. We store only a SHA-256 hash plus the first few characters of the key (for dashboard identification). If a key is ever exposed, revoke it from the dashboard and a fresh one is ready in seconds.
Larger teams can sign in through their own identity provider. We support Microsoft Entra ID today (other providers will follow), plus SCIM 2.0 for automatic provisioning and deprovisioning so a new hire shows up the moment HR adds them and is gone the moment they leave.
When you connect oakallow to Claude or ChatGPT through the MCP connector, the OAuth handshake happens on our own authorization server, not a third party's. PKCE with S256 is required on every authorization, refresh tokens rotate on every use, and every grant is recorded in our audit log.
We don't carry a formal third-party security attestation (SOC 2, ISO 27001) yet. The controls described above are what we run today; the formal report is on the roadmap. If your procurement process requires an attestation, please reach out and we'll share what we have plus our timeline. See the Trust page for the full picture of data handling and the subprocessors we use.
Have a security question we didn't cover?
Email security@oakallow.io and a human will get back to you.