The Stytch product will soon support role-based access control (RBAC)! See our RBAC guide at https://stytch.com/docs/b2b/guides/rbac/overview for more detailed explanations of our RBAC product.
RBAC policies must be set through the dashboard, but you can use various endpoints to assign Roles to Members and add implicit role assignments to Organizations and SSO connections (more details in the guide at https://stytch.com/docs/b2b/guides/rbac/role-assignment).
You can perform an RBAC authorization check when authenticating a JWT. This will use a locally cached version of the RBAC policy.
Some endpoints, such as Create Member, offer out-of-the-box handling of RBAC authorization checks if a session token or session JWT is passed in.
Other changes
The inner HTTP handler (not intended to be exposed as a public interface, but currently is just by virtue of Go packaging) has a required headers field now. As a note, in the future if we change this interface, we will not count it as a MAJOR version update. This class should be considered an implementation detail to any external users of the library. This refers to stytch.Client, not stytchapi.API or b2bstytchapi.API.
Many "product struct" constructors (like b2b.SessionsClient, for example) have updated fields in their New methods to make creation more obvious (and remove requirements around doing things like setting a JWKS after the struct has been instantiated). This shouldn't affect any user of the library, but is technically a breaking change. Like the previous point, in the future if we change this interface, we will not count it as a MAJOR version update. This class should be considered an implementation detail to any external users of the library. The expected entry point for consumers of this library is via stytchapi.API or b2bstytchapi.API and instantiating something like a b2b.OrganizationsClient directly is not supported.
Some methods will now have a new optional $METHODRequestOptions field – this is used to supply authorization data for RBAC (see previous point).
AuthenticateJWT and AuthenticateJWTLocal now accept an optional AuthorizationCheck parameter for performing RBAC checks. These will use a cached version of the project's RBAC policy in order to make an authZ verdict.
Built a LazyCache (which is intended to only be exposed internally) that is used for fetching the project's RBAC policy only when needed – by default this expires every 5 minutes, but only refreshes upon receiving a request that will use the value. This means that if your project does not use RBAC, the cache will never fetch the policy.
Additionally, this update features a large amount of documentation updates which should better reflect what you can find at https://stytch.com/docs.
RBAC
Other changes
stytch.Client, notstytchapi.APIorb2bstytchapi.API.b2b.SessionsClient, for example) have updated fields in their New methods to make creation more obvious (and remove requirements around doing things like setting a JWKS after the struct has been instantiated). This shouldn't affect any user of the library, but is technically a breaking change. Like the previous point, in the future if we change this interface, we will not count it as a MAJOR version update. This class should be considered an implementation detail to any external users of the library. The expected entry point for consumers of this library is viastytchapi.APIorb2bstytchapi.APIand instantiating something like ab2b.OrganizationsClientdirectly is not supported.$METHODRequestOptionsfield – this is used to supply authorization data for RBAC (see previous point).AuthenticateJWTandAuthenticateJWTLocalnow accept an optionalAuthorizationCheckparameter for performing RBAC checks. These will use a cached version of the project's RBAC policy in order to make an authZ verdict.LazyCache(which is intended to only be exposed internally) that is used for fetching the project's RBAC policy only when needed – by default this expires every 5 minutes, but only refreshes upon receiving a request that will use the value. This means that if your project does not use RBAC, the cache will never fetch the policy.