@rebasepro/server 0.13.0 → 0.13.1-canary.g06dbe5b

package/dist/auth/interfaces.d.ts

@@ -55,7 +55,21 @@ export interface OAuthProviderProfile {
     email: string;
     displayName?: string | null;
     photoUrl?: string | null;
-    /** Whether the OAuth provider has verified the user's email address */
+    /**
+     * Whether the provider reported that it verified this email address.
+     *
+     * This is not a display field. It is the sole authorization input to
+     * account linking: a `true` here lets the sign-in route attach the
+     * incoming identity to a pre-existing account that shares the address.
+     * Set it `true` **only** from a verification signal actually present in
+     * the provider's response — pass that signal through
+     * `providerVerifiedEmail()` rather than writing a literal, so a provider
+     * that reports nothing comes back `false`.
+     *
+     * `false` is not a failure: the user signs in and, if they already have an
+     * account, links through `POST /auth/link/<provider>`, which proves
+     * ownership with a live session instead of an unverified address.
+     */
     emailVerified?: boolean;
 }
 /**
@@ -138,6 +152,15 @@ export interface RefreshTokenInfo {
     revoked?: boolean;
     /** When the sign-in happened; carried across rotations, unlike createdAt. */
     sessionStartedAt?: Date;
+    /**
+     * The assurance level this session was established at. See
+     * {@link RefreshTokenSession.aal} — refresh reads it from here and mints
+     * the replacement access token at the same level.
+     *
+     * Absent on rows written before this column existed, and on repositories
+     * that do not store it; both read as `aal1`, the restrictive value.
+     */
+    aal?: "aal1" | "aal2";
 }
 /**
  * Identity of the sign-in a refresh token belongs to, threaded through
@@ -146,6 +169,16 @@ export interface RefreshTokenInfo {
 export interface RefreshTokenSession {
     id: string;
     startedAt: Date;
+    /**
+     * How this session was established: `aal2` only where a second factor was
+     * actually presented.
+     *
+     * Persisted because refresh has nothing else to go on. Deriving it at
+     * refresh time from "does this user have a factor?" would promote every
+     * pre-existing password-only session of a user who later enrolled — the
+     * assurance level is a property of the *sign-in*, not of the account.
+     */
+    aal?: "aal1" | "aal2";
 }
 /**
  * Password reset token info
@@ -408,6 +441,12 @@ export interface MfaFactor {
     verified: boolean;
     createdAt: Date;
     updatedAt: Date;
+    /**
+     * The highest TOTP time step ever accepted for this factor. A code whose
+     * step is at or below it has already been spent — see
+     * {@link MfaRepository.claimMfaFactorCounter}.
+     */
+    lastUsedCounter?: number | null;
 }
 /**
  * MFA challenge information
@@ -418,6 +457,8 @@ export interface MfaChallengeInfo {
     createdAt: Date;
     verifiedAt?: Date;
     ipAddress?: string;
+    /** Failed verifications recorded against this challenge so far. */
+    attempts?: number;
 }
 /**
  * Recovery code data structure
@@ -486,6 +527,32 @@ export interface MfaRepository {
      * Check if a user has any verified MFA factors
      */
     hasVerifiedMfaFactors(uid: string): Promise<boolean>;
+    /**
+     * Claim a TOTP time step for a factor: succeed once, then never again for
+     * that step or any earlier one.
+     *
+     * One statement, claim-and-act — `UPDATE … WHERE last_used_counter IS NULL
+     * OR last_used_counter < $counter RETURNING id`. A read-then-write would
+     * let two requests carrying the same code both pass the check before either
+     * wrote, which is precisely the replay this exists to stop.
+     *
+     * Optional so a repository written against an older release still compiles;
+     * where it is absent, an accepted code stays replayable for the rest of its
+     * window and the route says so in the log.
+     *
+     * @returns true when the step was claimed by this call, false when it had
+     *          already been spent.
+     */
+    claimMfaFactorCounter?(factorId: string, counter: number): Promise<boolean>;
+    /**
+     * Record a failed verification against a challenge and return the new
+     * total. Atomic (`UPDATE … SET attempts = attempts + 1 RETURNING attempts`)
+     * so concurrent guesses cannot share one increment.
+     *
+     * Optional; where it is absent the route falls back to the rate limiters
+     * alone.
+     */
+    recordMfaChallengeAttempt?(challengeId: string): Promise<number>;
 }
 /**
  * Combined auth repository interface for convenience

package/dist/auth/jwt.d.ts

@@ -30,6 +30,18 @@ export interface AccessTokenPayload {
  * Validates the secret strength to prevent deployment with default/weak secrets.
  */
 export declare function configureJwt(config: JwtConfig): void;
+/**
+ * Has this server been given a JWT secret?
+ *
+ * False on every backend that authenticates through an adapter — Firebase,
+ * Clerk, anything with its own tokens — because nothing calls
+ * {@link configureJwt} there. Signing paths still throw when it is false, since
+ * asking for a token from a server that cannot mint one is a mistake worth
+ * hearing about. Paths whose contract is *"tolerate the absence of auth"* must
+ * ask first: `optionalAuth` crashing a request because this backend does not do
+ * JWT is a 500 on a route that had already decided anonymous was acceptable.
+ */
+export declare function isJwtConfigured(): boolean;
 /**
  * Generate an access token (short-lived, 1 hour by default)
  */
@@ -86,6 +98,34 @@ export declare function getRefreshTokenTtlMs(): number;
  * Calculate refresh token expiration date
  */
 export declare function getRefreshTokenExpiry(): Date;
+/**
+ * The `purpose` claim carried by a credential that stands between "first factor
+ * accepted" and "session issued".
+ *
+ * A pre-auth token is NOT a session and must never be usable as one:
+ * {@link verifyAccessToken} refuses any token carrying a `purpose`, so this
+ * value cannot authenticate a request no matter which route it is presented to.
+ * The only thing that reads it is the MFA challenge pair, which exchanges it —
+ * plus a second factor — for a real session.
+ */
+export declare const MFA_PENDING_PURPOSE = "mfa-pending";
+/**
+ * Mint the short-lived credential handed back with an `MFA_REQUIRED` response.
+ *
+ * Short-lived on purpose: it is the window in which a caller who has proven the
+ * first factor may present the second, not a session to be carried around. Five
+ * minutes matches the challenge TTL.
+ */
+export declare function generateMfaPendingToken(uid: string, expiresInSeconds?: number): string;
+/**
+ * Verify a pre-auth token and return the user it was minted for.
+ *
+ * Returns `null` for anything else — including a perfectly valid *access*
+ * token, which must not be interchangeable with this one in either direction.
+ */
+export declare function verifyMfaPendingToken(token: string): {
+    uid: string;
+} | null;
 export interface DownloadTokenPayload {
     purpose: "file-read";
     path: string;

package/dist/auth/linkedin-oauth.d.ts

@@ -1,4 +1,5 @@
 import type { OAuthProvider } from "./interfaces";
+import { type OAuthCodeFlowPayload } from "./oauth-code-flow";
 export interface LinkedinUserInfo {
     linkedinId: string;
     email: string;
@@ -12,7 +13,4 @@ export interface LinkedinUserInfo {
 export declare function createLinkedinProvider(config: {
     clientId: string;
     clientSecret: string;
-}): OAuthProvider<{
-    code: string;
-    redirectUri: string;
-}>;
+}): OAuthProvider<OAuthCodeFlowPayload>;

package/dist/auth/mfa-gate.d.ts

@@ -0,0 +1,42 @@
+/**
+ * The gate between "first factor accepted" and "session issued".
+ *
+ * MFA used to be modelled as an optional step-up that no resource required: a
+ * user could enrol TOTP, print recovery codes, and change nothing about what a
+ * stolen password bought, because every session-minting route issued a full
+ * `aal1` token without ever asking whether the account had a second factor.
+ * This module is the ask. It lives apart from the routes so that there is one
+ * decision, made once, that `createSessionAndTokens` cannot be extended past —
+ * a new sign-in route inherits the gate by construction rather than by the
+ * author remembering it.
+ *
+ * @module
+ */
+import type { AuthRepository } from "./interfaces";
+/** Error code a client watches for to switch a sign-in into its second step. */
+export declare const MFA_REQUIRED_CODE = "MFA_REQUIRED";
+/** Shape carried in `error.details` of an {@link MFA_REQUIRED_CODE} response. */
+export interface MfaRequiredDetails {
+    /**
+     * Short-lived, purpose-scoped credential proving the first factor was
+     * accepted. It is refused as a session everywhere (`verifyAccessToken`
+     * rejects purpose-scoped tokens); `POST /auth/mfa/challenge` and
+     * `POST /auth/mfa/challenge/verify` are the only routes that accept it.
+     */
+    mfaToken: string;
+    /** The verified factors the caller may answer the challenge with. */
+    factors: Array<{
+        id: string;
+        factorType: string;
+        friendlyName?: string;
+    }>;
+}
+/**
+ * Refuse to mint a session for an account whose second factor has not been
+ * presented, handing back what the client needs to present it.
+ *
+ * A 401 rather than a 200 with a different body: a client that has not been
+ * taught about MFA must fail, not proceed. The credential in `details` is
+ * useless for anything except the challenge routes.
+ */
+export declare function assertMfaSatisfied(authRepo: AuthRepository, uid: string): Promise<void>;

package/dist/auth/mfa-routes.d.ts

@@ -4,4 +4,29 @@ import { HonoEnv } from "../api/types";
 import type { AuthModuleConfig } from "./routes";
 import { resolveAuthHooks } from "./auth-hooks";
 import type { AuthResponsePayload, TransformAuthResponseContext } from "@rebasepro/types";
-export declare function mountMfaRoutes(router: Hono<HonoEnv>, config: AuthModuleConfig, ops: ReturnType<typeof resolveAuthHooks>, parseBody: <T>(schema: z.ZodSchema<T>, body: unknown) => T, applyTransformHook?: (response: AuthResponsePayload, method: TransformAuthResponseContext["method"], request: Request, uid: string) => Promise<AuthResponsePayload>): void;
+interface MfaRoutesConfig {
+    router: Hono<HonoEnv>;
+    config: AuthModuleConfig;
+    ops: ReturnType<typeof resolveAuthHooks>;
+    parseBody: <T>(schema: z.ZodSchema<T>, body: unknown) => T;
+    buildAuthResponse: (user: {
+        id: string;
+        email: string;
+        displayName?: string | null;
+        photoUrl?: string | null;
+        emailVerified?: boolean;
+        isAnonymous?: boolean;
+        metadata?: Record<string, unknown> | null;
+    }, roleIds: string[], accessToken: string, refreshToken: string, providerId: string) => unknown;
+    createSessionAndTokens: (uid: string, userAgent: string, ipAddress: string, options?: {
+        skipMfaGate?: boolean;
+        aal?: "aal1" | "aal2";
+    }) => Promise<{
+        roleIds: string[];
+        accessToken: string;
+        refreshToken: string;
+    }>;
+    applyTransformHook?: (response: AuthResponsePayload, method: TransformAuthResponseContext["method"], request: Request, uid: string) => Promise<AuthResponsePayload>;
+}
+export declare function mountMfaRoutes(opts: MfaRoutesConfig): void;
+export {};

package/dist/auth/mfa.d.ts

@@ -25,6 +25,22 @@ export declare function generateTotp(secret: Buffer, timeStep?: number): string;
  * @returns true if the token is valid within the window
  */
 export declare function verifyTotp(secret: Buffer, token: string, window?: number): boolean;
+/**
+ * Verify a TOTP token and report *which* time step matched.
+ *
+ * RFC 6238 §5.2 requires that an accepted OTP not be accepted a second time,
+ * and a boolean cannot express what was accepted: with `window = 1` the same
+ * six digits stay valid for up to 90 seconds, so a code observed once — by a
+ * phishing relay, over a shoulder, in a pasted support message — can be
+ * presented again for the rest of that window. The caller records the returned
+ * counter against the factor and refuses anything at or below it.
+ *
+ * @param secret - The shared secret as a Buffer
+ * @param token - The 6-digit TOTP code to verify
+ * @param window - Number of time steps to check on each side (default: 1)
+ * @returns The matched time step, or `null` when no step in the window matches
+ */
+export declare function verifyTotpCounter(secret: Buffer, token: string, window?: number): number | null;
 /**
  * Generate a new TOTP secret and return the setup information
  *

package/dist/auth/microsoft-oauth.d.ts

@@ -1,16 +1,31 @@
 import type { OAuthProvider } from "./interfaces";
+import { type OAuthCodeFlowPayload } from "./oauth-code-flow";
 /**
  * Creates a Microsoft / Entra ID (Azure AD) OAuth Provider integration.
  *
  * Supports both personal Microsoft accounts and work/school (Azure AD) accounts
  * via the "common" tenant endpoint. Uses the authorization code flow.
+ *
+ * ## On `emailVerified`
+ *
+ * Microsoft Graph exposes no email-verification field, and `mail` is *not* a
+ * substitute: it is a directory attribute a tenant administrator sets to any
+ * string they like, through Graph or AAD Connect sync. With the default
+ * `tenantId: "common"` every Entra tenant in the world is an accepted issuer,
+ * so "there is a `mail` value" would mean "anybody who can create a free
+ * tenant can nominate any address" — including one that already has an account
+ * here.
+ *
+ * The only signal Microsoft offers is the `xms_edov` ("email domain owner
+ * verified") optional claim on the id_token, so that is what this provider
+ * reads, off a signature-verified token. If the app registration does not emit
+ * `xms_edov`, sign-in still works and the address comes back unverified —
+ * which routes the user to `POST /auth/link/microsoft` rather than silently
+ * handing them somebody else's account.
  */
 export declare function createMicrosoftProvider(config: {
     clientId: string;
     clientSecret: string;
     /** Tenant ID. Defaults to "common" which allows both personal and organizational accounts. */
     tenantId?: string;
-}): OAuthProvider<{
-    code: string;
-    redirectUri: string;
-}>;
+}): OAuthProvider<OAuthCodeFlowPayload>;

package/dist/auth/oauth-code-flow.d.ts

@@ -0,0 +1,66 @@
+import { z } from "zod";
+/**
+ * The authorization-code request shape every OAuth provider accepts, and the
+ * two derivations of it that were previously copy-pasted twelve times.
+ *
+ * Twelve providers declared their own `z.object({ code, redirectUri })` and
+ * each decided independently whether to accept a PKCE verifier (one did) and
+ * how to read a verification signal off the provider's profile response (five
+ * skipped the question and hardcoded `true`). One predicate, twelve
+ * implementations — so the controls below live here and every provider calls
+ * them, which is what makes it impossible for a thirteenth provider to ship
+ * without them.
+ */
+/** The request body every authorization-code provider consumes. */
+export interface OAuthCodeFlowPayload {
+    /** Authorization code returned to the client by the provider. */
+    code: string;
+    /**
+     * Redirect URI the code was issued against. Echoed to the token endpoint,
+     * which is what binds the code to the client that started the flow — and
+     * why the route allowlists it before `verify` ever runs
+     * (see `isRedirectUriAllowed`).
+     */
+    redirectUri: string;
+    /**
+     * PKCE verifier, when the client started the flow with a
+     * `code_challenge`. Forwarded to the token endpoint verbatim.
+     */
+    codeVerifier?: string;
+}
+/**
+ * Build the request schema for an authorization-code provider.
+ *
+ * `pkce` defaults to `"optional"`: the client decides whether it sent a
+ * `code_challenge`, and providers that do not implement PKCE simply never see
+ * a verifier because their clients never generate one. `"required"` is for
+ * providers that mandate PKCE (Twitter/X).
+ */
+export declare function oauthCodeFlowSchema(opts?: {
+    pkce?: "required" | "optional";
+}): z.ZodObject<{
+    code: z.ZodString;
+    redirectUri: z.ZodString;
+    codeVerifier: z.ZodString | z.ZodOptional<z.ZodString>;
+}, z.core.$strip>;
+/**
+ * The `code_verifier` token-endpoint parameter, or nothing.
+ *
+ * Returned as a spreadable object so a provider adds PKCE with one `...` in
+ * its existing body literal, rather than branching.
+ */
+export declare function pkceTokenParams(codeVerifier?: string): Record<string, string>;
+/**
+ * Normalise a provider's email-verification signal into the boolean that
+ * `OAuthProviderProfile.emailVerified` promises.
+ *
+ * The whole point is the default: anything that is not an affirmative
+ * verification signal — `undefined`, `null`, a missing field, an empty string,
+ * `false` — becomes `false`. A provider that reports nothing therefore cannot
+ * accidentally assert that it verified the address, which is exactly the
+ * mistake five providers had made.
+ *
+ * Accepts the string forms because OIDC issuers are inconsistent about whether
+ * `email_verified` is a JSON boolean or a string.
+ */
+export declare function providerVerifiedEmail(signal: unknown): boolean;

package/dist/auth/oauth-signin-policy.d.ts

@@ -0,0 +1,61 @@
+/**
+ * The two decisions the OAuth sign-in route makes before it will hand a caller
+ * an existing account, extracted so they are stated once for all twelve
+ * providers and can be tested without a provider, a network or a database.
+ */
+/** Why an incoming OAuth identity may not be auto-attached to an existing account. */
+export type AutoLinkRefusal = 
+/** The provider did not report that it verified the address. */
+"provider-email-unverified"
+/**
+ * The local account holds a password nobody ever proved they own: it was
+ * created through `POST /auth/register`, which does not verify the
+ * address. Attaching a provider identity to it would hand the session to
+ * whoever registered the address first — the classic pre-hijack.
+ */
+ | "local-account-unverified";
+export type AutoLinkDecision = {
+    allowed: true;
+} | {
+    allowed: false;
+    reason: AutoLinkRefusal;
+};
+/** The part of an existing user row the decision depends on. */
+export interface AutoLinkExistingUser {
+    emailVerified: boolean;
+    passwordHash?: string | null;
+}
+/**
+ * May an OAuth identity be attached to a pre-existing account found *by email*?
+ *
+ * Both sides have to be trustworthy, and only one of them used to be checked:
+ *
+ *  - the **provider** must have verified the address, or the caller has not
+ *    shown they control it;
+ *  - the **local account** must itself be trustworthy — either its address was
+ *    verified, or it has no password at all (it was created by an OAuth
+ *    sign-in or an invitation, so there is no credential an attacker could
+ *    have planted in advance).
+ *
+ * A refusal is not a dead end: `POST /auth/link/<provider>` attaches the
+ * identity once the caller proves ownership by holding a session.
+ */
+export declare function decideOAuthAutoLink(args: {
+    providerEmailVerified: boolean | undefined;
+    existingUser: AutoLinkExistingUser;
+}): AutoLinkDecision;
+/**
+ * Is `redirectUri` one the operator authorised?
+ *
+ * The provider's own registered-URI match is a real control but a coarse one:
+ * it authorises *every* URI registered on that OAuth client, so a `localhost`
+ * entry kept for development, or a second product sharing the client id, can
+ * mint codes this backend accepts. An empty or absent allowlist keeps the old
+ * behaviour (the provider's check is the only one) so existing deployments are
+ * unaffected; setting one narrows it to the origins this backend serves.
+ *
+ * Comparison is on origin plus path, with the origin lowercased and a trailing
+ * slash ignored — query strings and fragments are not part of the identity of a
+ * redirect URI, and neither is the case of the host.
+ */
+export declare function isRedirectUriAllowed(redirectUri: string, allowlist?: string[]): boolean;

package/dist/auth/oidc-id-token.d.ts

@@ -0,0 +1,61 @@
+import jwt from "jsonwebtoken";
+/**
+ * Minimal JWKS-backed id_token verification, shared by the OIDC providers.
+ *
+ * Apple's id_token used to be `split(".")` + `JSON.parse`, justified by the
+ * comment "we only need the payload". That skips `aud` — nothing confirmed the
+ * token was minted for *this* Services ID rather than another one under the
+ * same Apple team — along with `iss`, `exp` and the signature. Microsoft did
+ * not request an id_token at all and inferred verification from a directory
+ * attribute instead.
+ *
+ * Deliberately hand-rolled rather than pulling in a JWKS client: the only
+ * cryptography here is `jsonwebtoken`'s (already a dependency) and Node's own
+ * JWK→KeyObject import. What this file adds is key discovery and a cache.
+ */
+export interface OidcIdTokenClaims {
+    sub: string;
+    iss: string;
+    aud: string | string[];
+    exp: number;
+    email?: string;
+    email_verified?: boolean | string;
+    nonce?: string;
+    [claim: string]: unknown;
+}
+export interface VerifyOidcIdTokenOptions {
+    /** The compact JWS to verify. */
+    idToken: string;
+    /** JWKS endpoint of the issuer. */
+    jwksUri: string;
+    /**
+     * Expected `iss`. A `RegExp` is for multi-tenant issuers whose tenant id is
+     * part of the issuer URL (Entra ID with `tenantId: "common"`); everything
+     * else passes the exact string.
+     */
+    issuer: string | RegExp;
+    /** Expected `aud` — the client/services id this backend is configured with. */
+    audience: string;
+    /** Permitted signing algorithms. Defaults to RS256, which is what Apple and Entra use. */
+    algorithms?: jwt.Algorithm[];
+    /** Seconds of clock skew tolerated on `exp`/`iat`. Defaults to 60. */
+    clockToleranceSec?: number;
+    /** Expected `nonce`, when the client bound one to the authorization request. */
+    nonce?: string;
+    /** Injection point for tests; defaults to global `fetch`. */
+    fetchImpl?: typeof fetch;
+}
+/** Drops the JWKS cache. Exported for tests; nothing in the runtime calls it. */
+export declare function resetJwksCache(): void;
+/**
+ * Verify an id_token's signature, `aud`, `iss` and `exp`, and return its claims.
+ *
+ * Throws on any failure — callers treat a throw as "reject this sign-in",
+ * never as "continue without the claims".
+ */
+export declare function verifyOidcIdToken(options: VerifyOidcIdTokenOptions): Promise<OidcIdTokenClaims>;
+/**
+ * `verifyOidcIdToken` that reports failure as `null` and logs it, for the one
+ * call site that has to decide between "reject" and "degrade".
+ */
+export declare function tryVerifyOidcIdToken(providerId: string, options: VerifyOidcIdTokenOptions): Promise<OidcIdTokenClaims | null>;

package/dist/auth/rate-limiter.d.ts

@@ -54,6 +54,26 @@ export declare const defaultAuthLimiter: MiddlewareHandler<HonoEnv>;
  * 50 requests per 15 minutes per IP.
  */
 export declare const strictAuthLimiter: MiddlewareHandler<HonoEnv>;
+/**
+ * Limiter for `POST /auth/send-verification`, keyed by the authenticated user.
+ *
+ * That route had no limiter at all while every one of its email-sending
+ * siblings had one, and being authenticated is not the protection it looks
+ * like: registration does not verify the address it is given, so an attacker
+ * registers a victim's address, signs in to the account they just made, and
+ * loops the route. Each call mints a token and mails the victim.
+ *
+ * An IP limiter cannot express what is wanted here — the recipient is the
+ * quantity being protected, not the caller — so this one keys on the uid, which
+ * on this route is one-to-one with the recipient address (emails are unique per
+ * account). `strictAuthLimiter` still runs in front of it to bound the caller by
+ * IP; this bounds what any single address can be sent.
+ *
+ * Five per 15 minutes is generous for "I didn't get the email, resend it" and
+ * useless as a mail bomb. Unauthenticated requests fall back to the IP bucket so
+ * the limiter is never a no-op if it is ever mounted before the auth middleware.
+ */
+export declare const verificationEmailLimiter: MiddlewareHandler<HonoEnv>;
 /**
  * Key generator for API-key-based rate limiting.
  *
@@ -73,13 +93,28 @@ export interface DataRateLimitConfig {
     user?: number;
     /**
      * Per IP, for requests with no principal at all. Default 300.
-     * `null` disables the anonymous bucket entirely — used for routers whose
-     * anonymous traffic must not be throttled (public webhook functions).
+     * `null` disables the anonymous bucket entirely.
      */
     anonymous?: number | null;
+    /**
+     * Per IP, for anonymous requests to `/api/functions/*`. Default 3000 —
+     * deliberately far looser than {@link anonymous}, because the functions
+     * router is public by default for webhook receivers (Stripe, GitHub) whose
+     * bursts arrive from a handful of provider IPs and would trip the data
+     * API's ceiling.
+     *
+     * The looseness bounds the *value*, not the existence of the limit: this
+     * router is the one that invites anonymous callers, so it is the last one
+     * that should have no ceiling at all. `null` disables it — an explicit
+     * choice, which is what the hardcoded `anonymous: null` here used to be
+     * without any way to say otherwise.
+     */
+    anonymousFunctions?: number | null;
     /** Share counts across replicas. Defaults to this process's memory. */
     store?: RateLimitStore;
 }
+/** @see DataRateLimitConfig.anonymousFunctions */
+export declare const DEFAULT_FUNCTIONS_ANONYMOUS_LIMIT = 3000;
 /**
  * Rate limiting for the data API.
  *

package/dist/auth/rls-scope.d.ts

@@ -12,6 +12,31 @@
  * @module
  */
 import type { DataDriver } from "@rebasepro/types";
+/**
+ * The identity the trusted server plane runs as: `rebase.dataAsAdmin`, and any
+ * caller presenting the service key.
+ *
+ * Naming it makes the privilege legible, because it is narrower than it reads.
+ * This is **not** an RLS bypass — a driver scoped with it is an
+ * `AuthenticatedPostgresBackendDriver`, so every statement runs in a
+ * transaction that has done `SET LOCAL ROLE rebase_user` with
+ * `app.uid = 'service'`, and policies are evaluated. Two consequences worth
+ * knowing before you write a policy:
+ *
+ * - It passes the default policies through their `rolesOverlap(['admin'])`
+ *   arm — the same arm an application user holding the `admin` role passes.
+ * - `policy.serverContext()` compiles to `auth.uid() IS NULL` and is therefore
+ *   **false** for it. A collection with `disableDefaultPolicies: true` whose
+ *   only rule is `serverContext()` denies these writes (42501) and returns
+ *   zero rows for these reads.
+ *
+ * The true bypass is `rebase.sql()`, which runs on the owner connection and
+ * never goes near `withAuth`.
+ */
+export declare const SERVICE_IDENTITY: {
+    uid: string;
+    roles: string[];
+};
 /**
  * Scope a DataDriver via `withAuth()` for RLS.
  *

package/dist/auth/routes.d.ts

@@ -18,6 +18,14 @@ export interface AuthModuleConfig {
     defaultRole?: string;
     /** Optional array of OAuth providers */
     oauthProviders?: OAuthProvider<unknown>[];
+    /**
+     * Redirect URIs the OAuth routes will accept, for every provider.
+     *
+     * Left unset, the only check is the provider's own registered-URI match,
+     * which authorises every URI registered on that OAuth client. Compared on
+     * origin plus path; query and fragment are ignored, as is a trailing slash.
+     */
+    allowedRedirectUris?: string[];
     /** When true, blocks all self-registration regardless of `allowRegistration`. */
     disableSelfRegistration?: boolean;
     /**

package/dist/auth/slack-oauth.d.ts

@@ -1,4 +1,5 @@
 import type { OAuthProvider } from "./interfaces";
+import { type OAuthCodeFlowPayload } from "./oauth-code-flow";
 /**
  * Creates a Slack OAuth Provider integration (OAuth 2.0 / "Sign in with Slack").
  * Uses the OpenID Connect flow with the "openid,email,profile" scopes.
@@ -6,7 +7,4 @@ import type { OAuthProvider } from "./interfaces";
 export declare function createSlackProvider(config: {
     clientId: string;
     clientSecret: string;
-}): OAuthProvider<{
-    code: string;
-    redirectUri: string;
-}>;
+}): OAuthProvider<OAuthCodeFlowPayload>;

package/dist/auth/spotify-oauth.d.ts

@@ -1,4 +1,5 @@
 import type { OAuthProvider } from "./interfaces";
+import { type OAuthCodeFlowPayload } from "./oauth-code-flow";
 /**
  * Creates a Spotify OAuth Provider integration.
  * Uses the authorization code flow with the "user-read-email" scope.
@@ -6,7 +7,4 @@ import type { OAuthProvider } from "./interfaces";
 export declare function createSpotifyProvider(config: {
     clientId: string;
     clientSecret: string;
-}): OAuthProvider<{
-    code: string;
-    redirectUri: string;
-}>;
+}): OAuthProvider<OAuthCodeFlowPayload>;

package/dist/auth/twitter-oauth.d.ts

@@ -1,4 +1,5 @@
 import type { OAuthProvider } from "./interfaces";
+import { type OAuthCodeFlowPayload } from "./oauth-code-flow";
 /**
  * Creates a Twitter/X OAuth 2.0 Provider integration.
  *
@@ -11,8 +12,4 @@ import type { OAuthProvider } from "./interfaces";
 export declare function createTwitterProvider(config: {
     clientId: string;
     clientSecret: string;
-}): OAuthProvider<{
-    code: string;
-    redirectUri: string;
-    codeVerifier: string;
-}>;
+}): OAuthProvider<OAuthCodeFlowPayload>;