Strapi User Management | OpsBlu Docs

Strapi User Management

Strapi RBAC system covering admin roles, content-type permissions, API token scopes, and analytics data access controls.

Strapi uses a dual-layer RBAC system that separates admin panel users from API (public) users. Admin users access the Strapi back office and are controlled by Admin Roles with granular permissions on content types, plugins, and settings. API users (front-end consumers) are managed by the Users & Permissions plugin with its own role system. This separation means you configure permissions in two distinct places depending on whether you are managing editors or application consumers.

Permission model

Admin RBAC (back-office):

  • Admin Roles -- named roles assigned to admin accounts. Each role has a permission matrix covering every content type, plugin, and settings page.
  • Permission granularity -- per content type, you can allow/deny: create, read, update, delete, publish. Per plugin, you control access to specific features. Settings permissions cover general, API tokens, webhooks, and other configuration areas.
  • Conditions (Enterprise) -- Enterprise edition adds permission conditions like "only content the user created" for content-type-level row filtering.

Users & Permissions plugin (API):

  • API Roles -- roles assigned to front-end users. Default roles: Authenticated, Public.
  • Route-based permissions -- each role can access specific API routes (e.g., GET /api/articles, POST /api/comments). Permissions map to controller actions.

Built-in admin roles

Role Permissions Notes
Super Admin All permissions, cannot be restricted Created during Strapi setup, full access including role management
Editor Create, read, update, publish content. No settings or user management. Default content role
Author Create, read own content. Cannot publish or manage others' content. Restrictive authoring role

Custom admin roles are created at Settings > Administration Panel > Roles. Each custom role starts with no permissions and you build up access.

Common custom role patterns:

Custom role Permissions Use case
Content Manager All content type CRUD + publish, no settings Senior editors
Translator Update on specific content types, read on all Localization teams
Analytics Admin Read on all content types, custom plugin access Reporting and data teams
Developer Content Type Builder, API tokens, webhooks, no content Technical administration

Admin UI paths

Task Path
Manage admin users Settings > Administration Panel > Users
Admin roles and permissions Settings > Administration Panel > Roles
API users (front-end) Content Manager > Users (Users & Permissions plugin)
API roles and permissions Settings > Users & Permissions Plugin > Roles
API tokens Settings > API Tokens
Webhooks Settings > Webhooks
Content Type Builder Plugins > Content-Type Builder
Media Library settings Settings > Media Library

API access management

REST API:

  • Endpoints auto-generated per content type at /api/{pluralName}
  • Authentication: JWT Bearer token from /api/auth/local (Users & Permissions) or API token
  • Permissions enforced based on the authenticated user's API role

GraphQL API (plugin):

  • Enabled via @strapi/plugin-graphql
  • Schema auto-generated from content types
  • Same permission system as REST -- API role controls which queries/mutations are allowed

API Tokens:

  • Created at Settings > API Tokens
  • Three types: Read-only (GET only), Full access (all CRUD), Custom (select specific actions per content type)
  • Tokens are passed via Authorization: Bearer <token> header
  • Token types determine access regardless of content type permissions -- a Read-only token cannot create content even if the route is open
  • Tokens have optional expiration dates (7 days, 30 days, 90 days, or unlimited)

Transfer tokens (Strapi 4.6+):

  • Special tokens for strapi transfer CLI operations
  • Created at Settings > Transfer Tokens
  • Used for content migration between environments

Analytics-specific permissions

Strapi's analytics permissions depend on whether you consume analytics data or manage tracking configuration:

  • Content type permissions for analytics data -- if you store analytics events, metrics, or dashboard configurations as Strapi content types, admin role permissions control who can read/write them. Create a custom "Analytics" admin role with read-only access to analytics content types.
  • API tokens for data pipelines -- create a dedicated Read-only API token for your analytics service to query content metadata. Name it clearly (e.g., "Analytics Pipeline Token") and set an expiration.
  • Plugin access -- analytics plugins (if installed) appear as plugin permissions in the admin role matrix. Control which roles can access plugin configuration pages.
  • Webhook triggers -- configure webhooks at Settings > Webhooks to trigger analytics events on content publish/update. Creating webhooks requires the "Webhooks" setting permission.
  • Audit logs (Enterprise) -- Enterprise edition includes audit logs tracking admin actions (login, content changes, permission modifications). Access the log at Settings > Audit Logs. Requires the Audit Log settings permission.
  • Content versioning -- Strapi's draft/publish system and content history let you track when analytics-related content changed. The publishedAt and updatedAt fields are available via API for content freshness analysis.

To create a reporting-only admin role:

  1. Go to Settings > Administration Panel > Roles > Create New Role
  2. Under Content Types, enable read on all content types, disable create, update, delete, publish
  3. Under Plugins, enable read access to relevant plugin pages
  4. Under Settings, deny all settings access
  5. Assign to analytics team members

Sub-pages

Nach oben