Skip to main content

Secrets

authentik: 2026.11.0+

A secret is a named credential, such as an OAuth2 client secret, an LDAP bind password, or an SMTP password. Providers, sources, stages, and connectors reference a secret instead of storing the credential themselves. Several objects can share one secret, each secret has its own permissions, and authentik records an event whenever someone views or replaces a value.

Manage secrets in the Admin interface under System > Secrets. Every form that uses a credential has a secret picker, with buttons to create a secret, view its value, and, for text secrets, rotate it.

Secret types​

Choose a type when you create a secret. You can't change it afterward.

  • Text: any text value, which can span several lines, such as a password, token, or PEM-encoded private key. authentik can generate and rotate text values.
  • JSON: a JSON or YAML object, such as a Google service account key or a kubeconfig. authentik validates the value when you save it, and rejects values that have no JSON equivalent, such as YAML dates.
  • File: an uploaded binary file, such as a Kerberos keytab or credential cache.

Each credential field accepts only the types that fit it, and its secret picker lists only those secrets.

Storage​

warning

authentik stores secret values unencrypted in its database, the same way it stored these credentials before secrets existed. File values are base64-encoded, which is not encryption. Secrets don't replace a dedicated secrets manager such as HashiCorp Vault. Restrict access to the database and its backups.

Objects that use secrets​

An object holds a reference to a secret, not a copy of its value. When you change a secret's value, every object that references it uses the new value.

The following objects store their credentials as secrets:

  • OAuth2/OpenID providers (client secret)
  • Proxy providers (cookie secret)
  • RADIUS providers (shared secret)
  • SCIM providers (token and Basic authentication password)
  • Google Workspace providers and Microsoft Entra providers (credentials)
  • LDAP sources (bind password)
  • Kerberos sources (sync password, keytabs, and credential caches). A keytab or credential cache is either a File secret with its contents, or a Text secret with its location in the form TYPE:residual.
  • OAuth, Plex, and Telegram sources (consumer secret and tokens)
  • Duo, SMS, and email authenticator setup stages (API keys and SMTP passwords)
  • Captcha stages (private key) and email stages (SMTP password)
  • Google Chrome Device Trust authenticator stages, Google Chrome connectors, and Fleet connectors (credentials)
  • Notification transports (webhook URL)
  • Kubernetes service connections (kubeconfig)

Generated provider secrets​

When you create an OAuth2/OpenID, Proxy, or RADIUS provider without selecting a secret, the provider creates one with a generated value in its usual format:

  • OAuth2/OpenID client secrets: 128 characters
  • Proxy cookie secrets: 32 characters
  • RADIUS shared secrets: 40 characters

After creation, these providers always reference a secret. On OAuth2/OpenID and RADIUS providers you can select a different secret, but you can't clear the field. Proxy providers manage their cookie secret themselves; rotate it under System > Secrets.

API and blueprints​

Manage secrets through the /api/v3/secrets/secrets/ endpoint. The value is the write-only value field, so list and detail responses never include it. When you create a text secret without a value, the optional length field sets the length of the generated value. Use the view_value action to read a value and the rotate action to replace a text value with a generated one. See the API reference for request details.

Objects reference a secret by its UUID through fields named after the credential field they replace, with a _ref suffix. For example, client_secret_ref on OAuth2 providers, shared_secret_ref on RADIUS providers, bind_password_ref on LDAP sources, and sync_keytab_ref and spnego_ccache_ref on Kerberos sources. A request or blueprint that sets the old field, such as client_secret, fails with a validation error that names the _ref field to use instead.

Attaching a secret to an object through the API requires the same permissions as in the Admin interface. See Use a secret on another object.

In a blueprint, define the secret as its own entry and reference it with !KeyOf. If you omit value from a text secret, authentik generates one.

Example:

- model: authentik_crypto_secrets.secret
  id: my-app-client-secret
  identifiers:
      name: my-app client secret
- model: authentik_providers_oauth2.oauth2provider
  identifiers:
      name: my-app
  attrs:
      client_secret_ref: !KeyOf my-app-client-secret

Blueprint exports include secrets without their values, because value is write-only, the same as certificate private keys. Add the values to an exported blueprint before you import it elsewhere. Otherwise authentik generates new values for text secrets and rejects JSON and file secrets.

To reference a secret that already exists, use !Find:

client_secret_ref: !Find [authentik_crypto_secrets.secret, [name, my-app client secret]]