authentik 2025.8.0 → 2026.8.3

Redis removal

In previous versions, authentik used Redis for caching, tasks, the embedded proxy outpost's session store, and WebSocket connections. Since 2025.8, tasks were migrated to use Postgres. With this release we've also migrated caching, the embedded outpost, and WebSocket to Postgres, fully removing the need for Redis.

As a result of this change, it is expected that authentik will use roughly 50% more database connections to Postgres. Redis-related settings have also been removed and can be deleted from your configuration.

If your Postgres instance requires a TLS connection, authentik now requires TLS 1.3 or the Extended Master Secret extension to connect to Postgres.

Default OAuth scope mappings

In previous releases with the default scope mappings, we set the email_verified claim to true. As we don't have a single source of whether a users' email is verified or not, and claiming that it is verified could lead to security implications, this claim has been corrected to false.

Some applications may require this claim to be true to successfully authenticate users, in which case you can create a custom email scope mapping that returns email_verified as true.

For more information, refer to the Email scope verification documentation.

Following the upgrade instructions below will remove Redis from your installation. If you use authentik with an externally configured Redis, you can simply remove the Redis configuration from authentik; for more detailed information about upgrading authentik, refer to our Upgrade documentation.

RBAC

As a first step to overhaul authentik's access control system, much of how groups and roles work internally is altered in this release. We recommend you check any custom code (e.g. expression policies, property mappings) that deals with group/role memberships or access control.

Group name uniqueness

Warning

Make sure your group names are unique before starting the upgrade.

From 2024.6, authentik enforced group name uniqueness through the API. However, groups created earlier or groups created by non-API mechanisms (e.g. a sync from a Source) may have left groups with duplicate names in your system. With 2025.12, group name uniqueness will now be enforced on the database-level.

We played with automatically renaming duplicates, but ultimately found it too confusing for admins. Instead, we made the migration fail loudly in case offending groups exist and now require manual renaming.

Permission inheritance

Groups already inherit is_superuser from their ancestor groups. With 2025.12, groups will also inherit all permissions from their ancestor groups.

Group hierarchy

Groups can now have multiple parent groups. Specifically, the Group.parent field (which was a ForeignKey) is now migrated to Group.parents (which is a ManyToManyField).

User permissions

All permissions now must be attached to a role. The direct relationships between the User and Permission models still exist (User.user_permissions and User.userobjectpermission_set), but they are not used and will be removed in a future release.

Storage improvements

File storage has been reworked to unify media file configuration (icons, branding options), and allow future uses of file storage including CSV Data Exports.

Files stored by authentik are now served from the /files prefix, and not from /media anymore. Any custom reverse proxy configuration handling those paths will need to be updated.

Storage mount changes

If local storage is used, authentik now expects a mount at /data for file storage. The existing /media mount must be moved to /data/media.

For Docker Compose users, the migration is as follows:

# Shut down authentik
docker compose down
# Create the new storage folder
mkdir -p ./data
# Move the old media storage to the new location
mv ./media ./data/media
# Download the new Docker Compose with the updated paths and start authentik. See below for details.

Storage configuration changes

New storage configuration options are available. See the storage settings reference for details.

SCIM group syncing behavior

Users will now be filtered based on the policies bound to the application the SCIM provider is used with. There is now an option to select groups in the SCIM provider, which, if selected, will only sync those groups, and if no groups are selected, all groups will be synced. If you have a SCIM provider with a group filter setup, it will be deactivated and a configuration warning will be created, for you to review the configuration.

Policies / Property mappings

User.ak_groups has been deprecated. Users' groups are now accessed through User.groups. Usage of .ak_groups will continue to function, but will create a configuration warning event, at most every 30 days. We recommend you check any custom code (e.g. expression policies, property mappings) that deals with group memberships to update them if necessary.

Listening on multiple IPs

For advanced use cases, authentik now supports setting listening settings to a comma-separated list of IPs. With this change, the default IP we listen on changed from 0.0.0.0 to [::] to better match ecosystem standards. Some IPv4-only environments might need to adapt those settings.

PostgreSQL custom connection options are deprecated

The AUTHENTIK_POSTGRESQL__CONN_OPTIONS and its replica equivalent are deprecated and will be removed in the next version. It was never properly used and may cause future breakages. If you're looking for a specific usage, open an issue to discuss alternative solutions.

hash_password management command security improvements

The hash_password management command no longer accepts a password as a positional command-line argument (password was visible in the process list). Run the command without arguments to enter the password in a hidden interactive prompt:

docker compose run --rm server hash_password

For automation, pipe the password through standard input:

printf '%s' "$PASSWORD" | docker compose run --rm server hash_password

"Prevent duplicate device" in WebAuthn setup stage removed

The Prevent duplicate devices option of the WebAuthn authenticator setup stage has been removed. It compared attestation certificates, which manufacturers deliberately share across entire production batches, so it rejected legitimate enrollments of a second security key bought at the same time as the first. The option was disabled by default in 2026.5.4 and is now gone; no configuration is required to replace it, and no action is needed when upgrading.

Forwarded headers are now restricted to trusted proxies

Starting with authentik 2026.8, the authentik server only uses forwarded request headers such as X-Forwarded-Proto, X-Forwarded-Host, and X-Forwarded-For when the connection comes from a trusted proxy network. Previous versions did not apply this restriction consistently to all forwarded headers.

This change prevents clients from supplying forged proxy headers and more strictly enforces the existing trusted proxy configuration.

Before upgrading, verify that your reverse proxy sends the required proxy headers and that every address or network from which it connects directly to authentik is included in AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS.

An incorrect configuration can cause authentik to interpret HTTPS requests as HTTP, resulting in blocked mixed content, an endless loading indicator, or authentication errors.

PostgreSQL custom connection options are deprecated

The AUTHENTIK_POSTGRESQL__CONN_OPTIONS and its replica equivalent are deprecated and will be removed in an upcoming version. It was never properly used and may cause future breakages. If you're looking for a specific usage, open an issue to discuss alternative solutions.

This release does not introduce new configuration options, but it more strictly enforces trusted proxy configuration. Review the breaking change before upgrading. You can follow the upgrade instructions below; for more detailed information about upgrading authentik, refer to our Upgrade documentation.