Backend Integration of RBAC

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

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.

If you are using Session JWTs, the Member'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:

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 Member's Role will take effect within five-minutes, in addition to ensuring that the underlying session has not been revoked.

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 or not 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.

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 Member's roles will be instantly honored.

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

authz_check = {
  organization_id: 'organization-test-07971b06-ac8b-4cdb-9c15-63b17e653931',
  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 or not 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.

You can use the same pattern described in the Custom AuthZ Checks guide for authorizing requests related to Stytch Resources (e.g. stytch.self or stytch.organization), or you can directly pass the Member's Session Token or Session JWT into the Stytch API call to have Stytch perform authentication and authorization prior to honoring the request.

The sequence for how this flow works is as follows:

This allows the authentication and authorization checks to occur as close as possible to the action being taken, streamlining your handling.

Each backend SDK method that has RBAC authorization controls will have a method_options.authorization object where you can pass the session_jwt and session_token to have Stytch enforce RBAC on the request.

For example, if you receive an API request to remove a Member from an Organization you can pass the current Session JWT into the organizations.members.delete() call and Stytch will authenticate the session and perform an authorization check prior to honoring the call.

resp = stytch_client.organizations.members.delete(
  organization_id="organization-test-07971b06-ac8b-4cdb-9c15-63b17e653931",
    member_id="member-test-32fc5024-9c09-4da3-bd2e-c9ce4da9375f",
    method_options=DeleteRequestOptions(
        authorization=Authorization(
            session_jwt="eyJ...",
        ),
    ),
)