dominic-r · Sep 14, 2026 · Sep 14, 2026 · Sep 14, 2026 · Sep 14, 2026 · Sep 14, 2026
@@ -21,7 +21,7 @@ Typical use cases included remote-work, contractor, and BYOD environments where
 
 ## Configuration options
 
-- **Credentials**: Google service-account JSON used to access the Chrome Verified Access API.
+- **Credentials**: a **JSON** [secret](../../../../sys-mgmt/secrets/index.mdx) containing the Google service account key used to access the Chrome Verified Access API.
 - **Authenticator type name**: optional friendly name shown to the user in self-service settings.
 - **Configuration flow**: optional authenticated flow that exposes the stage in user settings.
 
@@ -58,7 +58,7 @@ More concretely:
 3. In **IAM** > **Service Accounts**, create a service account.
 4. Generate a JSON key from the service account's **Keys** tab.
 5. In the Google admin side, configure a new provider under **Chrome browser > Connectors** and point it at your authentik URL, for example `https://authentik.company/endpoint/gdtc/chrome/`.
-6. Paste the exported JSON key into the stage's **Credentials** field in authentik.
+6. In the stage's **Credentials** field, create or select a **JSON** secret containing the exported JSON key.
 
 ### Why this stage is different
 

@@ -70,4 +70,10 @@ The required permissions for this integration are documented in the Helm chart:
 
 To connect a remote cluster, install the [`authentik-remote-cluster` Helm chart](https://artifacthub.io/packages/helm/goauthentik/authentik-remote-cluster) in the target cluster and namespace.
 
-After installation, the chart outputs an example kubeconfig file. Add that kubeconfig to authentik to connect to the cluster.
+After installation, the chart outputs an example kubeconfig file. Store it as an authentik [secret](../../../sys-mgmt/secrets/index.mdx) and select that secret when you configure the remote connection:
+
+1. In the Admin interface, go to **System** > **Outpost Integrations**.
+2. Click **New Outpost Integration** and choose **Kubernetes**.
+3. Enter a name and disable **Local connection**.
+4. Beside the **Kubeconfig** field, click **Create secret**, select the **JSON** type, and paste the kubeconfig's YAML as the value.
+5. Select the new secret and save the integration.
@@ -17,7 +17,7 @@ To create a Google Workspace provider in authentik, you must have already [confi
 4. On the **New Google Workspace Provider** page, set the following configurations:
     - **Name**: provide a descriptive name (e.g. `GWS provider`)
     - Under **Protocol settings**:
-        - **Credentials**: paste the contents of the JSON file that you downloaded when [configuring Google Workspace](./configure-gws.mdx)
+        - **Credentials**: create or select a **JSON** [secret](../../../sys-mgmt/secrets/index.mdx) containing the JSON key that you downloaded when [configuring Google Workspace](./configure-gws.mdx).
         - **Delegated Subject**: enter the email address of the Google Workspace user that all authentik actions will be delegated to
         - **Default group email domain**: enter a domain which will be used to generate the email address for groups synced from authentik to Google Workspace
         - **User deletion action**: controls what happens in Google Workspace when a user is deleted from authentik. Defaults to **Delete**. See [Deletion and offboarding](./index.mdx#deletion-and-offboarding) for the available actions and their effects

@@ -12,6 +12,8 @@ To create a provider along with the corresponding application that uses it for a
 5. On the **Configure Provider** page, provide the required configuration settings.
 6. Click **Create Application** to create both the application and the provider.
 
+A confidential client's client secret is stored as a [secret](../../../sys-mgmt/secrets/index.mdx). If you don't select one, authentik creates a secret with a generated value. To share a client secret between providers, select the same secret on each. When you [rotate the secret](../../../sys-mgmt/secrets/manage-secrets.mdx#rotate-a-secret), clients that still use the old value are rejected, and if the provider has no signing key, ID tokens signed with the old value no longer validate. Update every client after rotating.
+
 :::info
 Optionally, configure the provider with the `offline_access` scope mapping. By default, applications only receive an access token. To receive a refresh token, applications and authentik must be configured to request the `offline_access` scope. Do this in the Scope mapping area on the **Configure OAuth2/OpenID Provider** page.
 :::
@@ -14,6 +14,10 @@ This provider requires the deployment of a [RADIUS outpost](../../outposts/index
 
 Currently, only authentication requests are supported.
 
+### Shared secret
+
+The shared secret is stored as a [secret](../../../sys-mgmt/secrets/index.mdx). If you don't select one when you create the provider, authentik creates a secret with a generated value. When you [rotate the secret](../../../sys-mgmt/secrets/manage-secrets.mdx#rotate-a-secret), the outpost receives the new value automatically, and RADIUS clients that still use the old value are rejected until you update them.
+
 ### Authentication flow
 
 Authentication requests against the Radius Server use a flow in the background. This allows you to use the same flows, stages, and policies as you do for web-based logins.

@@ -78,7 +78,7 @@ entries:
       # as these values will override existing attributes.
       # Note: When creating objects, identifiers and attrs are merged together.
       # On updates (state: present), only fields specified in attrs are modified - other
-      # fields (like auto-generated client_id/client_secret) are left unchanged.
+      # fields (like auto-generated client_id/client_secret_ref) are left unchanged.
       attrs:
           denied_action: message_continue
           designation: stage_configuration

@@ -69,7 +69,7 @@ For detailed instructions, refer to Google documentation.
 3. Select **Google Device Trust Connector** as the connector type, click **Next**, and configure the following settings:
     - **Name**: define a descriptive name, such as "chrome-device-trust".
     - **Google Verified Access API**
-        - **Credentials**: paste the contents of the JSON file (the key) that you downloaded earlier.
+        - **Credentials**: create or select a **JSON** [secret](../../../sys-mgmt/secrets/index.mdx) containing the JSON key that you downloaded earlier.
 
 4. Click **Finish**.
 

@@ -8,6 +8,32 @@ draft: true
 
 ## Breaking changes
 
+### Credentials are stored as secrets
+
+Credentials that were stored on providers, sources, stages, and connectors are now stored as [secrets](../../sys-mgmt/secrets/index.mdx), which those objects reference. This applies to credentials such as:
+
+- OAuth2/OpenID client secrets
+- Proxy provider cookie secrets
+- RADIUS shared secrets
+- LDAP and Kerberos source bind and sync passwords
+- OAuth, Plex, and Telegram source credentials
+- SCIM provider tokens and Basic authentication passwords
+- SMTP passwords
+- Duo, captcha, and SMS stage keys
+- Notification transport webhook URLs
+- Microsoft Entra and Fleet credentials
+- Google service account keys
+- Kubernetes kubeconfigs
+- Kerberos keytabs and credential caches
+
+During the upgrade, authentik creates a secret for each existing credential with its exact value, and copies existing role permissions to the new secrets. See [Permissions after upgrading](../../sys-mgmt/secrets/permissions.mdx#permissions-after-upgrading).
+
+The credential fields in the API and blueprints, such as `client_secret`, `shared_secret`, `bind_password`, and `token`, are replaced by reference fields named `<field>_ref`, such as `client_secret_ref`. Requests and blueprints that still set an old field fail with a validation error that names the new field. In blueprints, define the secret as its own entry and reference it with `!KeyOf` or `!Find`. Blueprint exports no longer include credential values, including OAuth2 client secrets and RADIUS shared secrets that earlier exports contained. See [API and blueprints](../../sys-mgmt/secrets/index.mdx#api-and-blueprints).
+
+:::info
+The previous credential database columns are kept until 2027.2 to support downgrades.
+:::
+
 ### RAC endpoints are now devices
 
 RAC providers now use [devices](../../endpoint-devices/index.mdx) instead of maintaining separate endpoints. This allows machines enrolled through connectors, such as the authentik agent, to be accessed directly through RAC without configuring them again.
@@ -66,6 +92,18 @@ The **Base URL** [system setting](../../sys-mgmt/settings.mdx#base-url), introdu
 
 - **Display names in `ak_send_email` recipients**: The `address`, `cc`, and `bcc` parameters of `ak_send_email` now accept `(name, email)` tuples and `"Name <email>"` strings, so emails sent from expressions can include a display name in the `To` and `CC` headers, matching the Email stage. See [`ak_send_email`](../../customize/policies/types/expression/reference.mdx).
 
+### Secrets
+
+Manage the credentials used by providers, sources, stages, and connectors under **System** > **Secrets**, or create them directly from the form that uses them.
+
+Each secret has its own permissions, so a role can edit an integration without being able to read its password. Viewing a value and replacing or rotating it require their own permissions, and authentik records an event each time someone does either.
+
+Several objects can reference the same secret, so you update a shared credential in one place. You can rotate text secrets from the Admin interface or the API. Rotation changes the value in authentik only, so update the clients that use it afterward.
+
+Secret values are stored unencrypted in the database, as these credentials were before.
+
+See [Secrets](../../sys-mgmt/secrets/index.mdx).
+
 ### Single sign-on into devices managed by the authentik agent
 
 A RAC provider signs into devices which are enrolled through the authentik agent as the user who launched the connection, with no credentials configured for the device. authentik issues a token for the device, the RAC outpost turns it into an SSH certificate, and the agent validates the token before accepting the login. See [the RAC provider documentation](../../add-secure-apps/providers/rac/index.mdx#signing-in-with-the-authentik-agent).

@@ -193,11 +193,11 @@ A user sets their password.
 
 ### `secret_view`
 
-A user views a token's/certificate's data.
+A user views the data of a token, certificate, or secret.
 
 ### `secret_rotate`
 
-A token was rotated automatically by authentik.
+A secret's value was replaced, either by [rotation](../secrets/manage-secrets.mdx#rotate-a-secret) or by entering a new value. authentik also records this event when it rotates a token automatically.
 
 ### `invitation_used`
 

@@ -0,0 +1,90 @@
+---
+title: Secrets
+description: "Store the credentials that providers, sources, stages, and connectors use."
+authentik_version: "2026.11"
+---
+
+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](./permissions.mdx), 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.
+
+- [Manage secrets](./manage-secrets.mdx): create, reuse, replace, rotate, and delete secrets.
+- [Secret permissions](./permissions.mdx): control who can see, use, and change a secret.
+
+## 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](./manage-secrets.mdx#rotate-a-secret) 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](https://api.goauthentik.io/) 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](./permissions.mdx#use-a-secret-on-another-object).
+
+In a [blueprint](../../customize/blueprints/index.mdx), define the secret as its own entry and reference it with [`!KeyOf`](../../customize/blueprints/v1/tags.mdx#keyof). If you omit `value` from a text secret, authentik generates one.
+
+**Example**:
+
+```yaml
+- 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`](../../customize/blueprints/v1/tags.mdx#find):
+
+```yaml
+client_secret_ref: !Find [authentik_crypto_secrets.secret, [name, my-app client secret]]
+```