Memberships and Permissions

Permissions

AuthRocket provides a very flexible permissions architecture. It is intended to give you substantial freedom in how you implement permissions while avoiding complex and hard-to-audit chains and dependencies.

Permissions are assigned to Memberships. As Memberships are usually used to associate a User with an Org, this makes it possible to assign separate permissions to each Org’s users, and conversely, to each Org a User belongs to.

For the simplified case where only Users are used, without Orgs, (as discussed in Simple accounts), it is possible to create a single Membership per User that does not have an Org association. This Membership can still have permissions assigned to it.

Permissions are arbitrary tags that are meaningful to your application. While called “permissions”, they can be names of roles, groups, or permissions, or anything else that’s meaningful to your application.

Each permission tag must match the regex /[a-z0-9*:;._-]/i. We recommend using : or . to delimit namespaces and * as a wildcard, eg: feature.admin, widget:*, or widget:12345. Each permission may be up to 62 characters and a maximum of 2000 permissions may be added to a membership.

Examples

Normal permissions

some_feature:admin
controller.action
controller.*

Group / set names

normal_users
power_users
admins

Object IDs

widget:12345
widget:0f7c1047-c517-47f6-a515-8fd83766e6b5
widget:*

Read / write

orders:ro
orders:rw

SSO / multi-app

app_one
app_two.admin
app_three.controller.action
app_four.*.*

These are just some of what’s possible. You can combine any of the above ideas or do something different entirely.

Expiration of Memberships

Memberships can also have an expiration date. By default Memberships do not expire.

Membership expiration is useful for ensuring that certain User/Org associations are only temporary.

For example, a contractor or temporary employee may be granted backend access to your app to perform some kind of account research. Since they aren’t permanent employees, you don’t want to forget to delete their access.

Or, perhaps your app allows customer service personnel to give themselves access to a customer’s Org to troubleshoot a problem. You want to ensure they don’t forget to remove this access, so it’s set to automatically expire after 4 hours.

You may even want to allow account owners to set expiration dates when they add team members to their account (see Single-owner accounts with team members).

When a Membership expires, the membership will be automatically deleted. In addition, a membership.deleted event will be triggered, which can be received by your app like any other webhook event.