Secret permissions
authentik: 2026.11.0+
A secret has its own permissions, separate from the providers, sources, stages, and connectors that use it. A role can maintain an integration without being able to read its password.
Assign secret permissions to roles, either on one secret or globally on all secrets. A global permission also covers unrelated secrets and secrets created later, so for a role that maintains one integration, assign permissions on that integration's secret.
These permissions control access through authentik. They don't protect the values from anyone with direct access to the database. See Storage.
Permissions for each task
| Task | Required permissions |
|---|---|
| Create a secret | Can add Secret, assigned globally |
| See a secret's name and type | Can view Secret |
| View, copy, or download its value | Can view Secret and View secret's value |
| Rename it | Can view Secret and Can change Secret |
| Replace its value | Can view Secret, Can change Secret, and Rotate secret's value |
| Rotate it | Can view Secret and Rotate secret's value |
| Attach it to an object | Can view Secret and View secret's value |
| Delete it | Can view Secret and Can delete Secret |
Can view Secret shows a secret's name and type, not its value.
Rotating doesn't reveal the new value. A role with Rotate secret's value but without View secret's value can rotate a secret without seeing the result. Assign both if the role must copy the new value to the clients that use it.
Use a secret on another object
To select a secret on a provider, source, stage, or connector, you need permission to create or change that object, and View secret's value on the secret. The secret picker lists only secrets that you have Can view Secret on. An object can send its credential to an external system, so seeing a secret's name isn't enough to attach it.
After an object references a secret, you can edit the object's other settings without permission to view the value. For example, you can rename an LDAP source without seeing its bind password. Users who log in through the object don't need any secret permissions.
Replacing or rotating a secret changes it for every object that uses it, without requiring permission to change those objects. Before you assign Rotate secret's value on a shared secret, check which objects use it.
Signing in with Plex while you edit a Plex source stores the new Plex token in the source's secret. Creating a Plex source this way needs Can add Secret, and updating an existing one needs Can change Secret and Rotate secret's value on its token secret.
Example:
A support role maintains an LDAP source but must not read its bind password. Assign the role Can view LDAP Source and Can change LDAP Source on the source, and Can view Secret on its bind password secret. The role can edit the source and keep its secret selected, but can't view, replace, or rotate the password.
Assign permissions on one secret
- In the Admin interface, go to System > Secrets.
- On the secret's row, click the permissions icon.
- Assign the permissions to the role.
A global permission on the role still applies after you remove an object permission. For the general steps, see Manage permissions. Users who work in the Admin interface also need the Can access admin interface permission.
Access to new secrets
Can add Secret doesn't grant any permission on the secrets a role creates, including secrets that a provider creates with a generated value. To let a role view, attach, or manage the secrets it creates, configure initial permissions.
Permissions after upgrading
The upgrade to authentik 2026.11 turns each existing credential into a secret with the same value, and copies role permissions from the object to its secrets as object permissions:
- Roles that could view or change the object get Can view Secret on its secrets.
- Roles that could previously read the credential through the API also get View secret's value. This applies to roles with change permission on OAuth2/OpenID providers, RADIUS providers, Plex sources, Kubernetes service connections, Google Workspace providers, Google Chrome connectors, and Google Chrome Device Trust authenticator stages, and to roles with view permission on notification transports.
The upgrade doesn't grant Can change Secret or Rotate secret's value to any role. Assign them where needed.
Initial permissions that included view or change permission on these object types are extended the same way, so roles that create these objects can still see the secrets created with them.