authentik 2023.6.0 → 2026.8.3

• Removal of PostgreSQL 11 support

As announced in the 2023.5 release notes (and postponed by a release), this release requires PostgreSQL 12 or newer. This is due to a changed requirement in a framework we use, Django.

This does not affect docker-compose installations (as these already ship with PostgreSQL 12), however it is still recommended to upgrade to a newer version when convenient.

For Kubernetes install, a manual one-time migration has to be done: Upgrading PostgreSQL on Kubernetes

• Changed nested Group membership behavior

In previous versions, nested groups were handled very inconsistently. Binding a group to an application/etc would check the membership recursively, however when using user.ak_groups.all() would only return direct memberships. Additionally, using user.group_attributes() would do the same and only merge all group attributes for direct memberships.

This has been changed to always use the same logic as when checking for access, which means dealing with complex group structures is a lot more consistent.

Policies that do use user.ak_groups.all() will retain the current behavior, to use the new behavior replace the call with user.all_groups().

This release changes the PostgreSQL dependency to require Version 12 or later, which only affects Kubernetes installs. See here for more info on upgrading.

• Requests with missing trailing slash are no longer redirected

In previous versions, requests to a path like /api/v3/core/users would be redirected to [...]/users/. This redirect would cause mutating requests (such as POST, PUT and PATCH) to fail as they would get redirected to [...]/users/. The redirect has been disabled, which will not have an impact on a correctly configured setup.

• It is only possible to upgrade to 2023.10 from 2023.8. This is due to a bug in the migrations which will be fixed in a future release (#7326).

• Warning: The first 2024.x version of this chart will see a rework that will include breaking changes. The breaking changes will be noted in the next Release notes.

Manual action is required

• Tenants have been renamed to brands

Tenants, which were previously used to change branding configuration, default flows, and several other settings, have been renamed to brands. The term "Brands" more accurately reflects their usage for configuring branding, logos, colors, and overall login flow behavior.

Existing tenant objects will automatically be renamed to brand objects. The API endpoints associated with brands have also been renamed.

Blueprints using authentik_tenants.tenant will need to be changed to use authentik_brands.brand.

For more information, refer to the documentation for brands.

Also, the event retention settings configured in brands (previously tenants, see above) have been removed and are now a system setting, managed in the Admin interface or via the API (see below).

There is no built-in migration path for this change. If you set something other than the default (days=365), you will need to update the setting in the admin interface.

• Helm chart breaking changes

The Helm Chart has a number of breaking changes. Find out more in the chart release notes.

Manual action may be required

• Required offline_access scope for Refresh tokens

The OAuth2 provider ships with a new default scope called offline_access, which must be requested by applications that need a refresh token. Previously, authentik would always issue a refresh token for the Authorization code and Device code OAuth grants.

Applications that require a refresh token will need their configuration to be updated to include the offline_access scope mapping.

• Database requirement changes

authentik now uses PostgreSQL schemas other than public.

If you have a custom PostgreSQL deployment, please ensure that the authentik user is allowed to create schemas. Usually, if the authentik user is owner of the database, it already can.

• Redis and cache configuration options have been improved

Thank you @PKizzle for this contribution!

Cache settings have been moved from the redis top-level config key to their own cache top-level config key.

Settings have also been added to configure the Redis instance/database used for tasks and websockets separately from cache. See here.

Typically, no changes to the configuration are required.

• Configuration options migrated to the Admin interface

The following config options have been moved from the config file and can now be set using the Admin interface (under System -> Settings) or the API:

• AUTHENTIK_AVATARS
• AUTHENTIK_DEFAULT_USER_CHANGE_NAME
• AUTHENTIK_DEFAULT_USER_CHANGE_EMAIL
• AUTHENTIK_DEFAULT_USER_CHANGE_USERNAME
• AUTHENTIK_GDPR_COMPLIANCE
• AUTHENTIK_IMPERSONATION
• AUTHENTIK_FOOTER_LINKS
• AUTHENTIK_REPUTATION__EXPIRY

When upgrading to 2024.2, the currently configured options will be automatically migrated to the database, and can be removed from the .env or helm values file afterwards.

• Icons are now in a public/ subfolder

If your media folder is /media, icons are now stored in /media/public. authentik will automatically migrate the icons upon upgrading.

Note that even though that folder is named public, the files stored here are not automatically public. This is due to the naming of the default PostgreSQL schema.

• User sessions will be invalidated after this upgrade.

As such, users will need to log back in. Immediately after the upgrade completes, users are logged out automatically and are then prompted to log in again. This only occurs once.

• Removal of deprecated metrics

These metrics were renamed because they did not adhere to Prometheus best practices. The old metrics were kept for backwards compatibility and have now been removed.

• authentik_outpost_flow_timing_get -> authentik_outpost_flow_timing_get_seconds
• authentik_outpost_flow_timing_post -> authentik_outpost_flow_timing_post_seconds
• authentik_outpost_ldap_requests -> authentik_outpost_ldap_request_duration_seconds
• authentik_outpost_ldap_requests_rejected -> authentik_outpost_ldap_requests_rejected_total
• authentik_outpost_proxy_requests -> authentik_outpost_proxy_request_duration_seconds
• authentik_outpost_proxy_upstream_time -> authentik_outpost_proxy_upstream_response_duration_seconds
• authentik_outpost_radius_requests -> authentik_outpost_radius_request_duration_seconds
• authentik_outpost_radius_requests_rejected -> authentik_outpost_radius_requests_rejected_total
• authentik_main_requests -> authentik_main_request_duration_seconds

• The shorthand parameter for --stage, -s for the ak test_email command has been changed to -S

Manual action may be required

• Configuration options migrated to the Admin interface

The following config options have been moved from the config file and can now be set using the Admin interface (under System -> Settings) or the API:

• AUTHENTIK_DEFAULT_TOKEN_LENGTH

When upgrading to 2024.4, the currently configured options will be automatically migrated to the database, and can be removed from the .env or helm values file afterwards.

PostgreSQL minimum supported version upgrade

With this release, authentik now requires PostgreSQL version 14 or later. We recommend upgrading to the latest version if you are running an older version.

The provided Helm chart defaults to PostgreSQL 15. If you are using the Helm chart with the default values, no action is required.

The provided Compose file was updated with PostgreSQL 16. You can follow the procedure here to upgrade.

Group names unicity

With this release, authentik now enforces unique group names. Existing groups with name collisions that were created in earlier versions can still exist, but any new groups you create will need a unique name. If changing attributes, permission-level, or parent on an existing group with a name collision, you need to also change its name to be unique. Note that changing members or roles associated with the group does not require a rename.

GeoIP and ASN context object

The context["geoip"] and context["asn"] objects available in expression policies are now dictionaries. Attributes must now be accessed via dictionary accessors. See our policy examples for the updated syntax.

With this release, authentik now requires PostgreSQL version 14 or later. We recommend upgrading to the latest version if needed. Follow the instructions here if you need to upgrade PostgreSQL with docker-compose.

Manual action is required

• LDAP property mappings simplification

LDAP property mappings have been reworked to remove Object field. With this release, instead of returning a single user or group attribute for each property mapping, you can now return several of them. Here is an example of what new property mappings look like:

    return {
        "username": ldap.get("uid"), # list_flatten is automatically applied to top-level attributes
        "attributes": {
            "phone": list_flatten(ldap.get("phoneNumber")), # but not for attributes!
        },
    }

This property mapping populates the username and attributes.phone attributes of a user at the same time, reducing the number of mappings that are run and thus improving performance. Additionally, they are more straightforward to read, and this change allowed us to implement property mappings for OAuth and SAML sources as well.

authentik will automatically convert existing property mappings to this new format, by generating some Python code for each of the existing property mappings expressions. Property mappings that are managed by authentik will automatically get updated to the new format.

If you have any custom property mappings, we recommend converting them to this new format.

• OAuth and SAML sources now sync groups by default

OAuth (specifically OpenID and Okta) sources now sync groups by default when a groups claim is available.

SAML sources now sync groups by default when a http://schemas.xmlsoap.org/claims/Group attribute is available in the assertion.

To disable that behavior, create an OAuth/SAML source property mapping with the expression below and assign it as a user property mapping on the source.

    return {
        "groups": [],
    }

• Terraform Resource rename

Several resources in the Terraform provider have been renamed to align with new functionality. This mainly applies to property mapping-related resources. With the authentik version 2024.8.1 of the Terraform provider, both the old and new resources are available, and resources can be moved to the new name using terraform state mv.

These resources have been renamed:

• authentik_property_mapping_google_workspace
• authentik_property_mapping_ldap
• authentik_property_mapping_microsoft_entra
• authentik_property_mapping_rac
• authentik_property_mapping_radius
• authentik_property_mapping_saml
• authentik_property_mapping_scim

Manual action may be required

• Changes to the external user type

Since the introduction of user types with 2023.8, the main difference between internal and external users has mostly been relevant when using the Enterprise version of authentik.

With this release, authentik improves support for B2C use-cases, which external users are intended for. It is now possible to configure a default application. External users not attempting to access a specific application will always be redirected to this default application.

As part of this, external users will no longer have access to the User and Admin interfaces. If you're using the open-source version and you require this workflow, you can change users to be Internal, which will have no side-effects. For Enterprise customers, please reach out to us with any questions.

Bulk changing the user type

In the container, run the command ak change_user_type --all --type internal to change all users to Internal. Instead of using --all you can also pass usernames to the command to only change individual users to internal.

• Changed HTTP healthcheck endpoints status code

For increased compatibility, the /-/health/live/ and /-/health/ready/ endpoints return 200 HTTP Status codes for successful checks. Previously these endpoints returned 204, which means in most cases no changes are required.

• Impersonation now requires providing a reason

You can disable this behavior in the Admin interface under System > Settings.

• Deprecated PostgreSQL USE_PGBOUNCER and USE_PGPOOL settings

With this release, the AUTHENTIK_POSTGRESQL__USE_PGBOUNCER and AUTHENTIK_POSTGRESQL__USE_PGPOOL settings have been deprecated in favor of exposing the underlying database settings: AUTHENTIK_POSTGRESQL__CONN_MAX_AGE and AUTHENTIK_POSTGRESQL__DISABLE_SERVER_SIDE_CURSORS.

If you are using PgBouncer or PgPool as connection poolers and wish to maintain the same behavior as previous versions, AUTHENTIK_POSTGRESQL__DISABLE_SERVER_SIDE_CURSORS must be set to true. Moreover, if you are using PgBouncer AUTHENTIK_POSTGRESQL__CONN_MAX_AGE must be set to null.

The newly exposed settings allow supporting a wider set of connection pooler configurations. For details on how these settings interact with different configurations of connection poolers, please refer to the PostgreSQL documentation.

These settings will be removed in a future version.

• Fixed behavior in Source stage

In previous versions, the Source stage would incorrectly continue with the initial flow after returning from the source, which didn't match the documented behavior.

With this release this behavior has been corrected and the source stage will now correctly run the selected enrollment/authentication flow before returning to the flow from which the source stage was executed.

• Deprecated and frozen :latest container image tag after 2025.2

Using the :latest tag with container images is not recommended as it can lead to unintentional updates and potentially broken setups.

The tag will not be removed, however it will also not be updated past 2025.2.

We strongly recommend using a specific version tag for authentik instances' container images, such as :2025.2.

• Reputation score limit: The default values for the new upper and lower limits on Reputation score are -5 and 5. This could break custom policies that rely on the reputation scores decreasing or increasing beyond these limits. You can set your custom limits under System > Settings.

• Deprecated and frozen :latest container image tag after 2025.2

Using the :latest tag with container images is not recommended as it can lead to unintentional updates and potentially broken setups.

The tag will not be removed, however it will also not be updated past 2025.2.

We strongly recommend using a specific version tag for authentik instances' container images, such as :2025.4.

• Helm chart dependencies update: Following Bitnami's changes to only publish latest version of containers, the Helm chart dependencies (PostgreSQL and Redis) will now be updated with each release.

For this release:

• The Redis chart will be upgraded to the latest version. As the image is not pinned, it will also get upgraded.
• The PostgreSQL chart will be upgraded to the latest version, but the image will remain pinned to 15.8.0-debian-12-r18.

For the next release:

• The Redis chart will be upgraded to the latest version again.
• The PostgreSQL chart will be upgraded to the latest version again, and the image will no longer be pinned, which will bring it to PostgreSQL major version 17. This will require following PostgreSQL major upgrade steps, for which we provide documentation.

For subsequent releases:

• The Redis chart will be upgraded to the latest version.
• The PostgreSQL chart will be upgraded to the latest version, with major upgrades being called out in authentik release notes.

We encourage users to pin their PostgreSQL image version.

Manual action might be required

Sessions are now stored in the database

Previously, sessions were stored by default in the cache. Now, they are stored in the database. This allows for numerous other performance improvements. On high traffic instances, requests to old instances after the upgrade has started will fail to authenticate.

• Helm chart dependencies upgrades:
• The PostgreSQL chart has been updated to version 16.7.4. The PostgreSQL image is no longer pinned in authentik's default values and has been upgraded from version 15 to 17. Follow our PostgreSQL upgrade instructions to update to the latest PostgreSQL version.
• The Redis chart has been updated to version 21.1.6. There are no breaking changes and Redis has been upgraded from version 7 to 8.

• Deprecated and frozen :latest container image tag after 2025.2

Using the :latest tag with container images is not recommended as it can lead to unintentional updates and potentially broken setups. The tag will not be removed, however it will also not be updated past 2025.2. We strongly recommend using a specific version tag for authentik instances' container images, such as :2025.6.

• CSS: We’ve made some improvements to our theming system. If your authentik instance uses custom CSS, you might need to review flow and user interfaces for any visual changes.

Worker and background tasks revamped

The authentik worker and background tasks have been reworked for better observability of tasks, and better configurability of scheduled tasks.

This rework also allowed us to not depend on Redis for background tasks. However, we replaced the engine used to manage these tasks, and as such, don't have a seamless migration path.

For instances with a high level of traffic, such as many users logging in, many sign up requests, etc., some tasks may be lost during the upgrade. Instances with low traffic can upgrade during periods of downtime.

To prevent losing tasks during the upgrade, instances with a high level of traffic should follow these instructions:

1. Start by upgrading the authentik server.
2. Inspect the old version task queue to check that all tasks are done. Execute the following commands in the not-yet-upgraded worker container:

docker-compose

docker compose exec worker bash -c 'DJANGO_SETTINGS_MODULE=authentik.root.settings celery -A authentik.root.celery inspect active'
docker compose exec worker bash -c 'DJANGO_SETTINGS_MODULE=authentik.root.settings celery -A authentik.root.celery inspect scheduled'
docker compose exec worker bash -c 'DJANGO_SETTINGS_MODULE=authentik.root.settings celery -A authentik.root.celery inspect reserved'

Kubernetes

kubectl exec -it deployment/authentik-worker -c worker -- bash -c 'DJANGO_SETTINGS_MODULE=authentik.root.settings celery -A authentik.root.celery inspect active'
kubectl exec -it deployment/authentik-worker -c worker -- bash -c 'DJANGO_SETTINGS_MODULE=authentik.root.settings celery -A authentik.root.celery inspect scheduled'
kubectl exec -it deployment/authentik-worker -c worker -- bash -c 'DJANGO_SETTINGS_MODULE=authentik.root.settings celery -A authentik.root.celery inspect reserved'

3. Wait for all these commands to report the old task queues as "empty"
4. Finish by upgrading the worker

Docker image deprecation notice for beryju/authentik and beryju/authentik-*

The beryju/authentik and beryju/authentik-* Docker images are no longer being updated. Users are now encouraged to use the following images:

• Server image:
• ghcr.io/goauthentik/server or authentik/server

• Outpost images:
• ghcr.io/goauthentik/ldap or authentik/ldap
• ghcr.io/goauthentik/proxy or authentik/proxy
• ghcr.io/goauthentik/rac or authentik/rac
• ghcr.io/goauthentik/radius or authentik/radius

We recommend updating your Docker Compose files or other container configurations to use these new image paths.

Database encoding requirements

The PostgreSQL database must now use the UTF8 encoding. This is the default encoding that PostgreSQL uses. Unless you have specifically chosen a different encoding when creating the authentik database, no change is needed.

Renamed/removed settings

The AUTHENTIK_WORKER__CONCURRENCY setting has been renamed AUTHENTIK_WORKER__THREADS. The old setting is still available as an alias and will be removed in a future release.

The following settings have been removed and no longer have an effect:

• AUTHENTIK_BROKER__URL
• AUTHENTIK_BROKER__TRANSPORT_OPTIONS
• AUTHENTIK_RESULT_BACKEND__URL

Renamed/removed metrics

The authentik_admin_workers metric has been renamed authentik_tasks_workers.

The following metrics have been removed:

• authentik_system_tasks
• authentik_system_tasks_time_seconds
• authentik_system_tasks_status

Instead, the following metrics are now available:

• authentik_tasks_total
• authentik_tasks_errors_total
• authentik_tasks_retries_total
• authentik_tasks_rejected_total
• authentik_tasks_in_progress
• authentik_tasks_delayed_in_progress
• authentik_tasks_duration_milliseconds

Prometheus metrics

The tasks metrics are no longer exposed by the server, but by the worker. For Helm chart users, add the following values to enable a ServiceMonitor to scrape those metrics:

worker:
    metrics:
        enabled: true
        serviceMonitor:
            enabled: true

Helm chart changes

Due to Bitnami upcoming changes to availability of their container images, the Helm chart default values have been updated to instead use docker.io/library/postgres and docker.io/library/redis. If you are setting custom values for either PostgreSQL or Redis, please review the associated Helm chart changes to update your values.

Redis has also been updated from 8.0 to 8.2.

From this point on, we recommend using the bundled PostgreSQL dependency for demonstration and test purposes only. See our installation documentation for alternatives to run PostgreSQL in a production environment.

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.