Skip to main content

Access Rules

Beta

This feature is in beta. Core behavior is stable, but some APIs or configuration may change before general availability.

Authentication also has its own access-rule surface.

Use auth.access to allow or deny specific authentication actions such as sign-up, sign-in, password reset, MFA verification, profile reads, session reads, OAuth redirects, refresh, and sign-out.

This is different from database, storage, database subscription, room, or push access rules:

  • Authentication access rules protect auth endpoints and auth actions
  • Other access rules protect product resources such as rows, files, channels, rooms, and notifications

Configuration​

import { defineConfig } from '@edgebase/shared';

export default defineConfig({
  auth: {
    access: {
      signUp(input, ctx) {
        const email = String(input?.email ?? '');
        return email.endsWith('@company.com');
      },
      signIn(_input, ctx) {
        return ctx.ip !== '203.0.113.10';
      },
      refresh(_input, ctx) {
        return ctx.auth !== null;
      },
      mfaTotpEnroll(_input, ctx) {
        return ctx.auth?.custom?.plan === 'pro';
      },
    },
  },
});

If a rule returns false, the server rejects the request with 403 Forbidden.

Signature​

type AuthAccessRule = (
  input: Record<string, unknown> | null,
  ctx: {
    request?: Request;
    auth?: AuthContext | null;
    ip?: string;
  },
) => boolean | Promise<boolean>;

What You Can Check​

  • input
    • Request payload for the current auth action
  • ctx.auth
    • Current authenticated user if one exists
  • ctx.ip
    • Client IP address
  • ctx.request
    • Raw request object

Supported Actions​

ActionPurpose
signUpEmail/password sign-up
signInEmail/password sign-in
signInAnonymousAnonymous sign-in
signInMagicLinkRequest a magic link
verifyMagicLinkComplete magic link sign-in
signInPhoneRequest phone OTP
verifyPhoneOtpComplete phone OTP sign-in
linkPhoneStart phone linking
verifyLinkPhoneComplete phone linking
signInEmailOtpRequest email OTP
verifyEmailOtpComplete email OTP sign-in
mfaTotpEnrollStart TOTP enrollment
mfaTotpVerifyConfirm TOTP enrollment
mfaVerifyComplete MFA challenge
mfaRecoveryComplete MFA via recovery code
mfaTotpDeleteDisable TOTP
mfaFactorsList MFA factors
requestPasswordResetRequest password reset
resetPasswordComplete password reset
verifyEmailVerify email
changePasswordChange password
changeEmailStart email change
verifyEmailChangeComplete email change
passkeysRegisterOptionsStart passkey registration
passkeysRegisterComplete passkey registration
passkeysAuthOptionsStart passkey sign-in
passkeysAuthenticateComplete passkey sign-in
passkeysListList passkeys
passkeysDeleteDelete a passkey
getMeRead current user profile
updateProfileUpdate current user profile
getSessionsList current user sessions
deleteSessionRevoke one session
getIdentitiesList linked identities
deleteIdentityRemove a linked identity
linkEmailLink email/password to an account
oauthRedirectStart OAuth sign-in
oauthCallbackComplete OAuth sign-in
oauthLinkStartStart OAuth linking
oauthLinkCallbackComplete OAuth linking
refreshRefresh JWT session
signOutSign out

Examples​

Restrict Sign-Up Email Domains​

auth: {
  access: {
    signUp(input) {
      const email = String(input?.email ?? '');
      return email.endsWith('@company.com');
    },
  },
}

Block Anonymous Sign-In By IP​

auth: {
  access: {
    signInAnonymous(_input, ctx) {
      return ctx.ip !== '203.0.113.10';
    },
  },
}

Require An Authenticated User For Profile Actions​

auth: {
  access: {
    getMe(_input, ctx) {
      return ctx.auth !== null;
    },
    updateProfile(_input, ctx) {
      return ctx.auth !== null;
    },
    getSessions(_input, ctx) {
      return ctx.auth !== null;
    },
    signOut(_input, ctx) {
      return ctx.auth !== null;
    },
  },
}

Gate MFA Enrollment By Plan​

auth: {
  access: {
    mfaTotpEnroll(_input, ctx) {
      return ctx.auth?.custom?.plan === 'pro';
    },
  },
}

Default Behavior​

  • If a specific auth.access.* rule is not defined, that action is not blocked by auth.access.
  • Built-in authentication requirements still apply:
    • session-protected routes still require a valid token
    • disabled users are still rejected
    • captcha, MFA, password policy, and provider configuration still apply

In other words, auth.access is an extra policy layer, not a replacement for the built-in auth flow checks.

See Also​