Security Policies

Standard HTTP Operations apply operation-specific request security. RequestSecurityPolicy can combine AuthRateLimit with bot protection; application authorization remains separate because rate limiting cannot decide tenant, role, ownership, or business access.

Some user-keyed policies validate the session before constructing their trusted user key; many session operations have no standard rate-limit rule. Treat each operation's implementation and documented policy as authoritative rather than assuming one universal order.

Durable Cloudflare policy

Alchemy v2 binds the Durable Object namespace to the auth Worker. Build the persistent limiter from that binding, then provide the standard policy once to HTTP Operations:

import {
  HttpLoginApprovalFinalizerCapability,
  HttpLoginApprovalStatusCapability,
  LoginNotificationReportCapability,
  PasswordEmailVerificationCapability,
  layerNoDeps as httpEndpointCapabilitiesLayerNoDeps,
} from "@effect-auth/core/HttpApi/HttpEndpointCapabilities";

const HttpEndpointCapabilitiesLayer = httpEndpointCapabilitiesLayerNoDeps({
  passwordEmailVerification: PasswordEmailVerificationCapability.Disabled(),
  loginNotificationReport: LoginNotificationReportCapability.Disabled(),
  loginApprovalStatus: HttpLoginApprovalStatusCapability.Disabled(),
  loginApprovalFinalizer: HttpLoginApprovalFinalizerCapability.Disabled(),
});

const AppRateLimiterLive = RateLimiterLive.pipe(
  Layer.provide(PersistenceRateLimiter.layer),
  Layer.provide(
    RateLimitStoreDurableObject.layer({ namespace: env.RATE_LIMITER })
  )
);

const AuthApiLive = CoreAuthHttpApiLive.pipe(
  Layer.provide(AuthRateLimitStandardLive()),
  Layer.provide(HttpAuthenticationCapabilitiesLive),
  Layer.provide(HttpEndpointCapabilitiesLayer),
  Layer.provide(Layer.merge(AppAuthServicesLive, AppRateLimiterLive))
);

The operation Layer captures both AuthRateLimit and one HttpAuthenticationCapabilities service, then uses that service's exact request-metadata snapshot for every maintained limiter input. Configure HttpAuthenticationCapabilitiesLive with CloudflareConnectingIp at a Cloudflare boundary or the deployment's validated X-Forwarded policy; do not rely on AuthHttpApiConfig or ambient raw capability services to change an already constructed operation. Presets and custom groups only bind that operation; wrapping it in the same policy again consumes budget twice. Primitive-only endpoints must arrange equivalent controls themselves. RateLimiterMemoryLive is process-local and unsuitable when counters must survive Worker isolate replacement.

Standard limits

Defaults use fixed windows. Multiple rules for one operation are required sequentially in one composed policy; consumption is not atomic, so an earlier counter remains consumed if a later rule denies. Policy constructors validate and freeze 1 through 16 rules; auth operation overrides validate and snapshot 1 through 8 rules when their Layer is built.

The standard profile contains exactly 54 operations. OAuth handlers select disjoint pre-authentication and post-validation subsets from the rows below; they do not consume the same rule twice during one request.

Use exact exported operation keys from AuthRateLimitStandardRules for overrides. The staged key column is also the exact key set accepted for that operation; unsupported staged keys fail configuration validation.

Override semantics

AuthRateLimitStandardLive({
  "auth.password.sign_in": [
    {
      id: "app.password.sign_in.ip",
      key: "ip",
      limit: 8,
      window: Duration.minutes(15),
    },
  ],
  "auth.magic_link.verify": null,
});

Rules support exact fixed-window and token-bucket algorithms. Empty arrays, unknown operations, unsupported staged keys, duplicate IDs/identities, malformed numbers/durations, and more than eight rules fail with value-free SecurityConfigurationError during Layer construction. Provider-authorization replacements must retain a pre-session ip rule; use null for an explicit opt-out rather than a user-only rule that would disappear for anonymous requests. Request-local Rules are revalidated before Privacy or persistence and malformed values map to a sanitized internal failure. Missing required subjects, including the selected trusted IP, fail closed. Password sign-in, sign-up, and reset-start principal rules use the configured identity registry's normalized identity; malformed or unsupported identities use a bounded generic fallback without performing an account lookup before limiting. Use null, Skip, or AuthRateLimitNoopLive only when another explicit control owns the risk.

Keys, proxies, and browser boundaries

Maintained cookie-auth browser APIs make an explicit origin-only choice and require the exact fail-closed origin policy. Core does not mount AuthCsrfMiddleware because it does not own CSRF-token issuance or browser delivery. Applications may instead choose origin plus app-owned double-submit, but must then own token entropy, delivery, rotation, expiry, and session binding; this is not an optional boolean on the maintained API.

Finally, compose session, role, tenant, ownership, recent-step-up, and business-resource guards outside AuthRateLimit. See App-owned Guards and Abuse Protection.

Rate-limit keys accept only canonical lowercase hexadecimal or base64url SHA-256 digests and use bounded versioned length framing for persistence identity. Persistence responses, Cloudflare RPC values, and versioned Durable Object state are checked structurally and fail closed as RateLimitStoreError when malformed. The Cloudflare adapter still uses one object per framed key; cardinality, hot-key capacity, and sharding remain deployment infrastructure work.

Maintained browser OAuth/device routes expose the standard auth 429 shape. OAuth protocol endpoints expose temporarily_unavailable with status 429. Both install a whole-second Retry-After, Cache-Control: no-store, and Pragma: no-cache; backend and Privacy failures are sanitized and fail closed without a retry header.

Provider-mode OAuth authorization codes use whole-second lifetimes from 1 second through 10 minutes and default to 5 minutes. Explicit expiresAt and expiresIn are mutually exclusive, and an explicit absolute expiry must also produce a whole-second delta from issuance. Device authorizations default to 10 minutes and accept 1 second through 7 days; their initial whole-second poll interval must be at least 1 second and no longer than the authorization lifetime. Every early poll atomically adds exactly 5 seconds, so an evolved bounded interval may place the next permitted poll after authorization expiry. The reference opaque issuers default access tokens to 1 hour and refresh tokens to 30 days, bound them to 24 hours and 365 days respectively, and require the access lifetime not to exceed the refresh lifetime when a refresh token is issued. These constructors snapshot validated TTLs and device user-code HMAC key material; issue paths reject malformed Unix-millisecond time or unsafe expiry addition before RNG, hashing, or storage. Verification and maintained memory, SQLite/D1, and PostgreSQL boundaries reject unsafe, fractional, future-issued, overlong, or incoherent authorization, poll, token, and family records without activating or writing them. Refresh rotation preserves the original family expiry and caps replacement access tokens at that boundary.

Handler-owned form parsing for device start, token, introspection, and revocation is IP-limited before content-type checks, body decoding, grant selection, or client credential parsing. Every token request uses only auth.oauth.token.ingress.ip at that pre-body stage. After grant decoding, authorization-code, refresh-token, and client-credentials requests use the auth.oauth.token IP stage plus disjoint applicable client and credential stages; device-code requests use the auth.oauth.device_authorization.poll IP stage plus disjoint client and device-code stages instead. The ingress, token IP, and poll IP operations can be overridden independently, and no operation/rule identity is consumed twice during one request. Framework-owned schema/query decoding for provider authorization and device browser routes still occurs before operation handlers. Only those pre-handler framework failures remain outside operation budgets; deployments that must budget them need a payload-independent limit at a trusted gateway or framework middleware boundary.