/
Contact usSee pricingStart building
Node
​

    About Stytch

    Introduction
    Integration Approaches
      Full-stack overview
      Frontend (pre-built UI)
      Frontend (headless)
      Backend
    Migrations
      Migration overview
      Migrating users statically
      Migrating users dynamically
      Additional migration considerations
      Zero-downtime deployment
      Defining external IDs for users
      Migrating from Stytch Consumer to B2B
      Exporting from Stytch
    Custom Domains
      Overview

    Authentication

    DFP Protected Auth
      Overview
      Setting up DFP Protected Auth
      Handling challenges
    Magic Links
    • Email Magic Links

      • Getting started with the API
        Getting started with the SDK
        Replacing your password reset flow
        Building an invite user flow
        Add magic links to an existing auth flow
        Adding PKCE to a Magic Link flow
        Magic Link redirect routing
    • Embeddable Magic Links

      • Getting started with the API
    MFA
      Overview
      Backend integration
      Frontend integration
      Remembered device flow
    Mobile Biometrics
      Overview
    M2M Authentication
      Authenticate an M2M Client
      Rotate client secrets
      Import M2M Clients from Auth0
    OAuth
    • Identity providers

      • Overview
        Provider setup
      Getting started with the API (Google)
      Add Google One Tap via the SDK
      Email address behavior
      Adding PKCE to an OAuth flow
    Connected AppsBeta
      Setting up Connected Apps
      Client types
    • Integration Guides

      • Integrate with AI agents
        Integrate with MCP servers deployed on Cloudflare
        Integrate with MCP servers on Vercel
        Integrate with CLI Apps
    • Resources

      • About Remote MCP Servers
        Consent Management
    Passcodes
      Getting started with the API
      Getting started with the SDK
    • Toll fraud

      • What is SMS toll fraud?
        How you can prevent toll fraud
      Unsupported countries
    Passkeys & WebAuthn
    • Passkeys

      • Passkeys overview
        Set up Passkeys with the frontend SDK
    • WebAuthn

      • Getting started with the API
        Getting started with the SDK
    Passwords
      Getting started with the API
      Getting started with the SDK
      Password strength policy
    • Email verification

      • Overview
        Email verification before password creation
        Email verification after password creation
    Sessions
      How to use sessions
      Backend integrations
      Frontend integrations
      Custom claims
      Custom claim templates
      Session tokens vs JWTs
      How to use Stytch JWTs
    TOTP
      Getting started with the API
      Getting started with the SDK
    Web3
      Getting started with the API
      Getting started with the SDK
    Trusted Auth Tokens
      How to use Trusted Auth Tokens

    RBAC

    Resources
      Overview
      Role assignment
    Integration Guides
      Start here
      Backend integration
      Headless frontend integration
      (Legacy) Implement RBAC with metadata

    3rd Party Integrations

    Planetscale
    Supabase
    Feathery
    Unit

    Testing

    E2E testing
    Sandbox values
Get support on SlackVisit our developer forum

Contact us

Consumer Authentication

/

Guides

/

RBAC

/

Integration Guides

/

Backend integration

Backend Integration of RBAC

Regardless of whether you are using Stytch's frontend SDKs, you should always perform server-side authentication and authorization checks before proceeding with a request.

Custom Resource Authorization Checks

Stytch's SDKs allow you to perform session authentication and authorization of your custom permissions in a single method call. Whether that method call is actually a local evaluation or makes an outbound call to Stytch depends on whether you are using Session Tokens or JWTs.

Using Session JWTs

If you are using Session JWTs, the User's Roles are contained in the JWT and authorization checks will be done locally during the lifetime of the JWT, without incurring any additional latency of an outbound call. If the JWT is not expired, the flow will look as follows:

RBAC sequence when using backend SDKs and unexpired JWT

When the authenticateJwt() method detects the JWT is expired, it will make an outbound call to Stytch to refresh the JWT. This ensures that any changes to the User's Role will take effect within five-minutes, in addition to ensuring that the underlying session has not been revoked.

RBAC sequence when using backend SDKs and JWTs

Stytch's backend SDKs will cache your Project’s RBAC policy and refresh it every five minutes, ensuring that any RBAC policy changes are incorporated into local evaluations within 5 minutes.

In code you'd want to perform the following check prior to honoring the user's request to create a new document:

authz_check = {
  organization_id: 'organization-test-07971b06-ac8b-4cdb-9c15-63b17e653931',
  resource_id: 'document',
  action: 'create',
}

resp = stytch_client.sessions.authenticateJwt(
  session_jwt="eyJ...",
  authorization_check=authz_check
)
if resp != 200:
    # Redirect user to login page
    return 'not authenticated', 401

if not resp.authorized:
    return 'unauthorized', 403

The authorized boolean will indicate whether the user is allowed to take the requested action, and the verdict array will contain the role(s) that granted them the ability to take that action on that resource.

Using Session Tokens

If you are using Session Tokens, session authentication always triggers an outbound call to Stytch and authorization will also be done on Stytch's servers. Any changes to the RBAC policy or the User's roles will be instantly honored.

RBAC sequence when using backend SDKs and Session Tokens

You can add authorization checks to your session authentication through the following:

authz_check = {
  resource_id: 'document',
  action: 'create',
}

resp = stytch_client.sessions.authenticate(
  session_token='mZAYn5aLEqKUlZ_Ad9U_fWr38GaAQ1oFAhT8ds245v7Q',
  authorization_check=authz_check
)
if resp != 200:
    # Redirect user to login page
    return 'not authenticated', 401

if not resp.authorized:
    return 'unauthorized', 403

The authorized boolean will indicate whether the user is allowed to take the requested action, and the verdict array will contain the role(s) that granted them the ability to take that action on that resource.

Custom Resource Authorization Checks

Using Session JWTs

Using Session Tokens