OAuth 2.1 compliance

Overview

Our authorization server is implemented with @cloudflare/workers-oauth-provider (MIT) running on Cloudflare Workers. Tokens are opaque bearer strings, stored encrypted in Cloudflare KV with the access token itself as key material. A stolen KV row is unreadable without a valid token.

The consent screen is hosted by oakallow at https://api.oakallow.io/authorize. User authentication uses the same passkey + email-OTP system as the rest of oakallow.

Endpoints

Scopes

Two scopes are advertised in the authorization-server metadata. The user picks which to grant on the consent screen; clients should request the minimum they need.

• mcp:read
  List your tools, view pending approvals, check permissions, and read activity logs.
• mcp:write
  Create approval requests, decide approvals you are authorised to decide, and mint run tokens.

Supported flows

• Authorization Code with PKCE. The only interactive grant we accept. code_challenge_method must be S256.
• Refresh Token. Rotated on every use; previous token remains valid until the new one is first redeemed, which tolerates one-shot retries without race conditions. Reuse after rotation revokes the chain.
• Dynamic Client Registration (RFC 7591) and Client ID Metadata Documents (CIMD, the MCP-recommended successor) are both supported. Clients can pick either.

Not accepted: implicit flow, resource-owner password credentials, plain PKCE.

Compliance evidence

We comply with OAuth 2.1 BCP and the MCP Authorization Specification (2025-03-26). Concrete claims and where to verify them:

• ✓ PKCE required, S256 only. Plain method rejected.
  OAuthProvider configured with allowPlainPKCE: false. Requests without code_challenge or with code_challenge_method=plain receive invalid_request.
• ✓ No implicit flow, no resource-owner password credentials
  allowImplicitFlow: false. The token endpoint accepts only authorization_code and refresh_token grants.
• ✓ Authorization codes are single-use
  Library invalidates the authorization code on first redemption (RFC 6749 §10.5).
• ✓ Exact-match redirect URI
  Redirect URIs are matched character-for-character against the registered set. Wildcards and substring matches are not supported (RFC 6749 §3.1.2.3).
• ✓ Refresh-token rotation with brief overlap window
  Each refresh issues a new refresh_token; the previous token remains valid until the new one is first used. Reuse of an already-rotated refresh_token revokes the entire refresh chain (OAuth 2.1 BCP §6.1).
• ✓ Confidential-client secrets hashed at rest
  Client secrets are hashed before storage. Plaintext is shown once at registration and never again.
• ✓ Resource indicators (RFC 8707) honoured
  Tokens are bound to the resource parameter from the authorization request. Tokens issued for one resource cannot be replayed against another.
• ✓ Audit log of every authorize, token, refresh, revoke, denial
  Every event is recorded in oauth_audit (D1) with timestamp, IP, client, scope, and event type. Surfaced in the user dashboard under Security, OAuth activity.
• ✓ CIMD (Client ID Metadata Documents) advertised at the protocol level
  Our authorization-server metadata advertises client_id_metadata_document_supported: true. MCP clients that prefer CIMD over RFC 7591 Dynamic Client Registration will discover that automatically and use the cleaner identity model. Verifiable at /.well-known/oauth-authorization-server.

Token lifetimes

• Access token: 1 hour.
• Refresh token: 30 days, rotated on every refresh.
• Authorization code: 10 minutes, single use.
• Client registration: persists until revoked. Clients can be deleted by the user from the dashboard or by the client itself via the registration management endpoint.

Revocation

Three ways to revoke:

• The user opens the dashboard at /dashboard/security → Connected Applications → Revoke.
• The client calls POST /revoke with the access or refresh token (RFC 7009).
• An admin revokes the grant from the admin app for compliance reasons. The user is notified by email.

Access tokens have a 1-hour lifetime, so revocation is fully effective within an hour without an introspection round-trip.

Reporting issues

Suspect a vulnerability or non-compliance? Email security@oakallow.io. See our privacy policy and terms of service for the broader platform commitments.