Roles vs Permissions | laravel-permission | Spatie SPATIE Laravel Permission ===================== spatie.be/open-source [Docs](https://spatie.be/docs) [Laravel-permission](https://spatie.be/docs/laravel-permission/v7) Best-practices Roles vs Permissions Version v7 v6 v5 v4 v3 Other versions for crawler [v7](https://spatie.be/docs/laravel-permission/v7) [v6](https://spatie.be/docs/laravel-permission/v6) [v5](https://spatie.be/docs/laravel-permission/v5) [v4](https://spatie.be/docs/laravel-permission/v4) [v3](https://spatie.be/docs/laravel-permission/v3) - [ Introduction ](https://spatie.be/docs/laravel-permission/v7/introduction) - [ Support us ](https://spatie.be/docs/laravel-permission/v7/support-us) - [ Prerequisites ](https://spatie.be/docs/laravel-permission/v7/prerequisites) - [ Installation in Laravel ](https://spatie.be/docs/laravel-permission/v7/installation-laravel) - [ Upgrading ](https://spatie.be/docs/laravel-permission/v7/upgrading) - [ Questions and issues ](https://spatie.be/docs/laravel-permission/v7/questions-issues) - [ Changelog ](https://spatie.be/docs/laravel-permission/v7/changelog) - [ About us ](https://spatie.be/docs/laravel-permission/v7/about-us) Basic Usage ----------- - [ Basic Usage ](https://spatie.be/docs/laravel-permission/v7/basic-usage/basic-usage) - [ Direct Permissions ](https://spatie.be/docs/laravel-permission/v7/basic-usage/direct-permissions) - [ Using Permissions via Roles ](https://spatie.be/docs/laravel-permission/v7/basic-usage/role-permissions) - [ Enums ](https://spatie.be/docs/laravel-permission/v7/basic-usage/enums) - [ Teams permissions ](https://spatie.be/docs/laravel-permission/v7/basic-usage/teams-permissions) - [ Wildcard permissions ](https://spatie.be/docs/laravel-permission/v7/basic-usage/wildcard-permissions) - [ Blade directives ](https://spatie.be/docs/laravel-permission/v7/basic-usage/blade-directives) - [ Defining a Super-Admin ](https://spatie.be/docs/laravel-permission/v7/basic-usage/super-admin) - [ Using multiple guards ](https://spatie.be/docs/laravel-permission/v7/basic-usage/multiple-guards) - [ Artisan Commands ](https://spatie.be/docs/laravel-permission/v7/basic-usage/artisan) - [ Middleware ](https://spatie.be/docs/laravel-permission/v7/basic-usage/middleware) - [ Passport Client Credentials Grant usage ](https://spatie.be/docs/laravel-permission/v7/basic-usage/passport) - [ Example App ](https://spatie.be/docs/laravel-permission/v7/basic-usage/new-app) Best Practices -------------- - [ Roles vs Permissions ](https://spatie.be/docs/laravel-permission/v7/best-practices/roles-vs-permissions) - [ Model Policies ](https://spatie.be/docs/laravel-permission/v7/best-practices/using-policies) - [ Performance Tips ](https://spatie.be/docs/laravel-permission/v7/best-practices/performance) Advanced usage -------------- - [ Testing ](https://spatie.be/docs/laravel-permission/v7/advanced-usage/testing) - [ Database Seeding ](https://spatie.be/docs/laravel-permission/v7/advanced-usage/seeding) - [ Exceptions ](https://spatie.be/docs/laravel-permission/v7/advanced-usage/exceptions) - [ Extending ](https://spatie.be/docs/laravel-permission/v7/advanced-usage/extending) - [ Cache ](https://spatie.be/docs/laravel-permission/v7/advanced-usage/cache) - [ Events ](https://spatie.be/docs/laravel-permission/v7/advanced-usage/events) - [ Custom Permission Check ](https://spatie.be/docs/laravel-permission/v7/advanced-usage/custom-permission-check) - [ UUID/ULID ](https://spatie.be/docs/laravel-permission/v7/advanced-usage/uuid) - [ PhpStorm Interaction ](https://spatie.be/docs/laravel-permission/v7/advanced-usage/phpstorm) - [ Other ](https://spatie.be/docs/laravel-permission/v7/advanced-usage/other) - [ Timestamps ](https://spatie.be/docs/laravel-permission/v7/advanced-usage/timestamps) - [ UI Options ](https://spatie.be/docs/laravel-permission/v7/advanced-usage/ui-options) Roles vs Permissions ==================== Best-Practice for thinking about Roles vs Permissions is this: **Roles** are best to only assign to **Users** in order to "**group**" people by "**sets of permissions**". **Permissions** are best assigned **to roles**. The more granular/detailed your permission-names (such as separate permissions like "view document" and "edit document"), the easier it is to control access in your application. **Users** should *rarely* be given "direct" permissions. Best if Users inherit permissions via the Roles that they're assigned to. When designed this way, all the sections of your application can check for specific permissions needed to access certain features or perform certain actions AND this way you can always **use the native Laravel `@can` and `can()` directives everywhere** in your app, which allows Laravel's Gate layer to do all the heavy lifting. Example: it's safer to have your Views test `@can('view member addresses')` or `@can('edit document')`, INSTEAD of testing for `$user->hasRole('Editor')`. It's easier to control displaying a "section" of content vs edit/delete buttons if you have "view document" and "edit document" permissions defined. And then Writer role would get both "view" and "edit" assigned to it. And then the user would get the Writer role. This also allows you to treat permission names as static (only editable by developers), and then your application (almost) never needs to know anything about role names, so you could (almost) change role names at will. Summary: - **users** have `roles` - **roles** have `permissions` - app always checks for `permissions` (as much as possible), not `roles` - **views** check permission-names - **policies** check permission-names - **model policies** check permission-names - **controller methods** check permission-names - **middleware** check permission names, or sometimes role-names - **routes** check permission-names, or maybe role-names if you need to code that way. Sometimes certain groups of `route` rules may make best sense to group them around a `role`, but still, whenever possible, there is less overhead used if you can check against a specific `permission` instead. ### FURTHER READING: [@joelclermont](https://github.com/joelclermont) at [masteringlaravel.io](https://masteringlaravel.io/daily) offers similar guidance in his post about [Treating Feature Access As Data, Not Code](https://masteringlaravel.io/daily/2025-01-09-treat-feature-access-as-data-not-code)