Sulu admin API token authentication scope for non-production testing

Restricting API Access for Testing

To limit a test API user to safe, read-only access on /api/admin, you must avoid assigning the ROLE_ADMIN role, which grants full destructive permissions. Instead, follow these steps:

1. Navigate to Security → Roles in the Sulu admin UI.
2. Create a new custom role (e.g., ROLE_API_READ_ONLY).
3. Assign only the view permissions for the specific content types or system modules required for your integration test.
4. Go to Security → API Users, create your test user, and assign this custom role.

To verify the restriction, attempt a POST or DELETE request to an admin endpoint using the test token; the server should return a 403 Forbidden response.

Token Lifecycle and Firewall Behavior

Expiration and Revocation

Token expiration is not automatic. The sulu_api firewall validates the Bearer token against the API User entity in the database. If no explicit expiration date is set on the API User record, the token remains valid indefinitely. To revoke access, you must either delete the API User or manually change the token string in the database.

Version Consistency (Sulu 2.x LTS vs 2.4)

Bearer token header parsing is consistent across Sulu 2.x LTS and 2.4. Both versions rely on the underlying Symfony Security component's stateless firewall configuration. Because the firewall is stateless, no session is maintained, and the Authorization: Bearer {token} header must be provided with every request.

Implementation Assumptions

This guidance assumes a standard Sulu installation where the sulu_api firewall is configured as stateless: true in security.yaml. Note that permissions are cached; if you modify a test user's roles, you may need to clear the Symfony cache for the changes to take effect immediately.

Diagnostic Detail Needed: Are you using a custom UserProvider or a modified security.yaml that overrides the default sulu_api firewall behavior?