Single logout with authentik: why sign-out has to reach every application
Single logout ends the user's session in every connected application when they sign out of one of them. Without it, a user who signs out of a portal or the identity provider can still be signed in to the mail client, the wiki or the ticketing tool, and anyone who sits down at the same machine can open those applications. That gap matters on shared workstations, in kiosk-style environments and in audits that ask how quickly access ends. authentik 2025.10 added back-channel and front-channel single logout for SAML providers and front-channel logout for OAuth2/OIDC providers, according to the authentik 2025.10 release notes. As of authentik 2026.8, the project is OpenID Certified for the RP-Initiated, Front-Channel and Back-Channel logout profiles, per the authentik 2026.8 release notes.
Certification and provider support describe what authentik does, not what your applications do. Single logout is a chain: authentik must send the logout signal, and each relying application must accept it, clear its own local session and enable that behavior in its configuration. Many applications support only one of the channels, some support none, and some clear the session only after a user clicks a button inside the application. Before you commit to a design, list every application that must sign out with the user, then confirm for each one which logout mechanism it supports, whether it is enabled by default, and whether it needs a published logout endpoint reachable from authentik. Ask each application vendor or project for this in writing rather than assuming it from the protocol name.
Plan the test before you change the configuration. Confirm the authentik version you run, because the release notes describe different capabilities by version, and check the release notes for any logout-related settings that changed in your upgrade path. Then sign in to two or three applications, sign out from one, and check each of the others in a fresh browser session, both for the front-channel and back-channel cases. Record which applications end the session and which do not, and treat any application that stays signed in as an open finding for the design review, not a cosmetic issue.
Which logout mode fits SAML and OIDC applications
SAML back-channel logout has authentik send a logout request directly from server to server to the application's single logout endpoint, so the browser is not needed to deliver the signal. The application must accept a signed SAML LogoutRequest at that endpoint, match it to the session it issued, and end that session on its side. Because the message travels server to server, it does not depend on third-party cookies, which makes it the more dependable choice when browsers restrict cross-site requests.
- Application support: the application must expose a SLO endpoint that accepts back-channel requests and must be able to verify the signature on the request.
- Network path: authentik must reach the application's endpoint over the network, which matters for applications on private networks or behind strict egress rules.
- Session matching: the application needs to map the session identifier in the request to its own local session, not only to the user name.
- Failure mode: if the application ignores the request or rejects the signature, the user stays signed in there while authentik has already ended the session.
- Confirm first: check the application's documentation for back-channel SLO support and the certificate it expects before you configure the provider.
Confirm with each application's vendor whether back-channel SLO is supported and which endpoint and signing requirements apply.
SAML front-channel logout uses the user's browser to carry the logout message. authentik returns a page that loads the application's logout endpoint in the browser, so the application ends its session when the browser makes that request. This works without a server-to-server connection, but it relies on the browser sending the application's cookies along with a cross-site request, which modern browsers increasingly restrict.
- Browser dependency: the logout only completes if the browser can load the application's endpoint and send its session cookie with that request.
- Typical failure: the browser blocks a third-party cookie or cross-site request, the application never receives the logout, and the user remains signed in there.
- Tab closed early: if the user closes the browser before the logout frames finish loading, the signal may never arrive.
- Application support: the application must accept logout requests from the browser and handle them without a confirmation step.
- Test in each browser: verify behavior in every browser your users run, including any privacy settings your organization enforces.
Treat front-channel SAML logout as a best-effort signal and pair it with back-channel logout where the application supports it.
OIDC front-channel logout works like its SAML counterpart: the identity provider asks the browser to load logout URLs registered by each relying party, and each application ends its own session when that request arrives. The application must register its logout URI with authentik, and authentik includes it in the logout response to the browser. The same browser-cookie constraints apply, so the result depends on the browser and the application's session handling.
- Registration: the application's front-channel logout URI must be configured on the authentik provider, and the application must accept requests on it.
- Session identifier: where the application uses the session identifier in the logout request, it must check that value against its own session before it ends the session.
- Cookie behavior: logout completes only when the browser sends the application's cookies with the cross-site request.
- Failure mode: a blocked request leaves the application session active while the identity provider session has ended.
- Verify with real logins: sign in to each application, sign out at authentik, and confirm the application session is gone.
Check the application's OIDC logout support in its own documentation before you rely on front-channel behavior.
OIDC back-channel logout has authentik send a signed logout token to each relying party's registered endpoint, so the application can end the matching session without involving the browser. The token identifies the user and session, and the application must validate its signature and claims before it acts on it. This mode is the stronger choice for applications that serve API clients or run in environments where browsers restrict cross-site requests.
- Logout token: the application must validate the token's signature, issuer, audience and event claims before it ends any session.
- Endpoint reachability: authentik must reach the application's back-channel endpoint, so network paths and firewall rules must allow the request.
- Session scope: the application should end sessions tied to the identified session or user, and it should not treat the message as a general sign-out for unrelated sessions.
- Offline clients: tokens or API clients that do not hold a browser session still need a plan for revocation.
- Check conformance: authentik documents OpenID Certified status for the back-channel and front-channel logout profiles as of 2026.8, which helps with interoperability, but you must still test each application.
Confirm the application's back-channel endpoint and token validation rules before you enable the mode.
RP-initiated logout starts at the application rather than at authentik. The application sends the user to authentik's end-session endpoint, and authentik ends the identity session and then returns the user to the post-logout redirect URI the application supplies. This mode is a user-facing action, so its outcome depends on the application sending the request correctly and on the redirect URI being registered.
- Post-logout redirect URI: the URI must be registered on the authentik provider, and it must match exactly what the application sends.
- Legacy installs: before authentik 2026.5, all OAuth2 redirect URIs were treated as Authorization type, so integration guides tell older installs not to configure a Post Logout URI. Check your version before you copy steps from current guides.
- Application session: RP-initiated logout ends the identity session, but the application must still clear its own session when the user returns.
- Failure mode: a missing or mismatched redirect URI stops the user at an error page or leaves the application session active.
- Test the return path: confirm the user lands on the intended page after sign-out, and that signing in again asks for credentials.
Review the application's logout settings and the authentik version in use before you finalize the redirect URIs.
Logout settings in authentik and when each one fits
This table compares the SAML and OIDC logout options in authentik, the redirect URI types that affect sign-out, and the application-side settings to check for each. Read each row against the application you are connecting, because the right choice depends on what that application supports and on your authentik version.
| Setting | What it does | When it fits | What to verify in the application |
|---|---|---|---|
| SAML back-channel logout | authentik sends a logout message directly from server to server to the application's SLO endpoint | Applications that accept server-side logout notifications and need sessions ended even when the browser is closed | The application exposes a single logout service that accepts back-channel requests, and it trusts authentik's signing certificate |
| SAML front-channel logout | authentik redirects the browser through each application's logout endpoint in turn | Applications that only support browser-based SLO, or where the user's browser must clear the application's own cookies | Browser redirects complete without being blocked, and the application returns the user to a sensible page afterward |
| OIDC back-channel logout | authentik posts a signed logout token to the application's registered back-channel logout URI | Server-side applications that keep their own sessions and can validate logout tokens | The logout URI is reachable from authentik, the application validates the token signature and issuer, and it invalidates sessions by subject or session ID |
| OIDC front-channel logout | authentik loads the application's logout URI in a hidden frame during sign-out | Browser-based applications that clear local session state on a frame request | Third-party cookie rules in the browser do not block the frame, and the application clears its session on that request |
| Post-logout redirect URI (Authorization type) | Used to send the user back to the application after sign-out in versions where all redirect URIs were treated as Authorization type | Installs where the post-logout target was entered as an ordinary redirect URI | Confirm in the authentik version in use whether the redirect URI type setting is available before relying on it |
| Post-logout redirect URI (Post Logout type) | Restricts where authentik may send the user after sign-out, separate from sign-in redirects | Recent authentik versions, where a dedicated Post Logout URI type is available for each application | Use only on versions that offer the type, and check that the URI matches the application's configured post-logout address exactly |
| Pre-2026.5 installs | All OAuth2 redirect URIs were treated as Authorization type | Installs on earlier versions should not configure a Post Logout URI, because integration guides advise against it | Confirm your running version first, then follow the guide that matches it |
Post-logout redirect URIs and the 2026.5 change
A post-logout redirect URI tells the OpenID Connect provider where to send the browser after the session ends. Once authentik has cleared its session and the application has been notified, the user lands on that address instead of an error page or the identity provider's login screen. The value must match one of the registered URIs exactly, character for character, including the scheme, host, port, path and any trailing slash. Partial matches, wildcard-style assumptions or a URI copied from a test environment will fail, and the user will see a redirect error at the end of sign-out even though the session itself was ended. Treat the registered list as an allowlist and keep it as short as the application needs.
The 2026.5 change matters most for older installs. Before authentik 2026.5, every OAuth2 redirect URI was treated as the Authorization type, so the separate Post Logout URI setting was not a reliable place to register sign-out destinations. For that reason, integration guides written for those versions tell administrators not to configure a Post Logout URI at all. Upgrading to 2026.5 or later changes this behavior, but an existing application configured under the old model may still need its redirect settings reviewed. Confirm which release your deployment runs, then check the integration guide for each application before adding a Post Logout URI, because some applications expect the value in a specific field and others ignore it.
Before changing anything in production, record the current release, the redirect and post-logout values for each OAuth2 or OIDC provider, and the logout behavior the application expects. Test the sign-out path in a staging instance on the same release, confirm the browser lands on the intended page, and check that the application's own session is also gone. If an application's documentation does not mention a post-logout setting, ask the vendor or its maintainers which URI format they support rather than guessing. Keep the change in your change log, since a later upgrade can alter how these values are read.
Setting up single logout step by step
This sequence takes you from a confirmed authentik release line to tested sign-outs across SAML and OIDC applications, so each provider's logout behavior is set deliberately and checked before users depend on it.
Confirm the authentik version and release line
Start by checking which authentik version is running in your environment and whether it sits on a release line that receives security fixes. Your platform or identity team does this against the server and worker containers, since both must run the same version. Single logout behavior differs by release: SAML back-channel and front-channel logout arrived in 2025.10, and the Post Logout URI handling for OAuth2 redirect URIs changed in 2026.5. Confirm the supported lines on the security policy page before you change anything. You are done when you have a written version number, a note on whether it is on a supported line, and a list of the logout features your release includes.
Enable the logout mode on each provider
In the authentik admin interface, open each SAML and OAuth2/OIDC provider that belongs to an application in the logout chain and choose the logout mode your application supports. SAML providers offer back-channel and front-channel options, and OAuth2/OIDC providers offer front-channel and back-channel options. Record the choice per provider, because a single application can behave differently from the next. Confirm the setting by reopening each provider and checking that the saved mode matches your record. You are done when every provider in scope has a documented logout mode.
Set redirect and post-logout URIs
For each OAuth2/OIDC provider, set the allowed redirect URIs to the exact callback addresses your application uses, then set the post-logout redirect URI to the page users should land on after sign-out. On releases before 2026.5, all redirect URIs were treated as Authorization type, so integration guides tell older installs not to configure a Post Logout URI. Check your version from step one before filling this field. For SAML, confirm the single logout URL and the entity ID match what the application expects. You are done when a test sign-out returns the browser to the intended page without an error and the saved values match the application's configuration.
Configure the application side
Your application team now sets the matching values on the relying party: the logout endpoint, the post-logout redirect target, and, for SAML, the single logout service location and whether it signs or expects signed logout requests. Many applications keep these settings in separate admin screens from the sign-in configuration, so check both. Ask each application owner to confirm which logout channel their product supports, since some products implement only one. You are done when each application's logout settings are written down against the authentik provider it pairs with.
Verify certificates and endpoints are reachable
Confirm that the signing certificates authentik publishes for each SAML provider are the ones the application trusts, and that certificate rotation has a planned owner. Then test that every logout endpoint is reachable from the network path the browser or back-channel call uses, including through reverse proxies and any load balancer. Back-channel logout requires the application to reach authentik or authentik to reach the application, depending on the flow, so firewall rules and DNS need checking in both directions. You are done when a request to each endpoint returns the expected response code and certificate fingerprints match the application's trust store.
Run test sign-outs across the application chain
Sign in to one application, open a second application in the same browser, then sign out from the first and confirm the second requires a new login. Repeat from each application in the chain and from a second browser to check back-channel behavior. Record which applications ended the session, which kept a session open, and any error pages or log entries in authentik's event log. Re-run the tests after any change to a provider or application. You are done when every pairing in the chain has a recorded result, and any gap has an owner and a fix planned.
Testing sign-out with real applications
Single logout only counts when it works across the applications your users actually open. The cards below cover the test cases that expose the usual gaps: partial sign-out, browser privacy settings, stale sessions, missing redirect configuration and the log evidence you will need afterward.
Sign out from each application
Sign in to every connected application, then sign out from one of them. Check that each other application ends its session when the next page loads or the next request is made. Repeat this from each application in turn, because the logout path often works from one client and fails from another. Record which application did not end its session, since that points to a single provider or client setting.
Use a second browser profile
Run the sign-in and sign-out tests in a second browser profile or a separate browser that shares no cookies with the first. A single profile can hide problems because stale cookies from earlier tests make a session look active. A clean profile shows what a user with no leftover state would see, and it also confirms that sign-in still works from zero.
Block third-party cookies
Test with third-party cookies blocked in the browser, since front-channel logout depends on the browser loading logout requests inside frames or redirects. Some browsers and privacy modes block these by default. A failure here typically means front-channel logout is not reaching the applications, so confirm which logout channel each application uses before changing provider settings.
Test with expired sessions
Let a session expire, or shorten the session lifetime in a test environment, and then trigger logout from an application. Confirm the application handles an already-ended session without an error page or a loop back to sign-in. Also check that a user whose session expired in authentik sees a clean state in each connected application.
Test a missing post-logout URI
Remove the post-logout redirect URI from one test application and observe what happens after sign-out. Older installs need this check most, because before authentik 2026.5 all OAuth2 redirect URIs were treated as Authorization type and integration guides tell those installs not to configure a Post Logout URI. Confirm the exact behavior your installed version produces before writing the setting into your runbook.
Capture event logs as evidence
For each test run, record the time, the test case, the application used and the result, and export the matching authentik event entries for the logout and session events. These records show what happened on the provider side and support change reviews and audit requests. Store the test evidence with the configuration version it applies to, so a later upgrade can be compared against the same cases.
Questions teams ask before configuring single logout
How much effort does single logout take to configure in authentik?
The effort depends mainly on how many applications you need to sign out and how many of them already support a logout endpoint. Each application needs its own provider settings in authentik, a matching configuration on the application side, and a test that a sign-out in one place ends the session in the others. For SAML, you also need to decide between back-channel and front-channel logout for each application, because the two behave differently when a browser is closed or blocked. Teams that inventory their applications first usually find that the configuration work is repetitive, while the unknowns sit in the applications themselves. Ask any partner to break the estimate down per application and per protocol so you can see where the time goes.
Can our team set up single logout without outside help?
Yes, a team with administrator access to authentik and to each application can do the work in house, provided someone owns the protocol details. Authentik 2025.10 added back-channel and front-channel single logout for SAML providers and front-channel logout for OAuth2/OIDC, so the capability exists in that release line and later. The harder part is usually coordination: each application team must confirm which logout method it accepts, where its sign-out endpoint lives, and how it behaves when the logout request fails. Outside help tends to be most useful for the test plan, for documenting the decisions, and for reviewing the configuration before it reaches production. Whichever route you choose, confirm the authentik version you run before you start.
What do application owners need to provide for single logout?
Application owners need to confirm the logout behavior their application supports and provide the exact endpoints and settings it expects. For SAML, that includes whether the application accepts back-channel logout requests, front-channel logout, or both, and which signing and metadata details it uses. For OIDC, it includes the post-logout redirect URIs it will accept and whether it can receive front-channel or back-channel logout notifications. Owners also need to tell you how their session behaves after logout, including any cached tokens or remember-me features that could keep a user signed in. Ask each owner for a test account and a named contact for the test window, because sign-out checks cannot be verified without access to the running application.
How long does testing single logout take with many applications?
Testing time grows with the number of applications and with the number of logout paths you need to verify, so the duration cannot be stated before the inventory is complete. Each application typically needs a sign-in, a sign-out from authentik, a check that the other applications were signed out, and a check of the post-logout redirect. Failure cases add more work: a closed browser tab, a blocked third-party cookie, an unreachable application, and a user who signs out from one application only. Group applications by logout method so that one test pattern covers several of them. Ask for a written test plan with the number of scenarios per application and the people required on each side before you agree on a schedule.
Does the open source edition of authentik include single logout?
The authentik repository places most of its code under the MIT license, and the code in the authentik/enterprise/ directory is under a separate enterprise license defined in that directory. Single logout for SAML and OAuth2/OIDC providers is part of the provider feature set documented in the release notes, so confirm in the repository and the release notes for your exact version whether the code paths you plan to use sit under MIT or under the enterprise license. Do not assume from the pricing page alone, because the listed Enterprise-only features do not name single logout. Check the license file and the directory layout yourself, and ask your legal or procurement team to review the result before you commit to a design.
What should we ask a partner to include in a single logout quote?
Ask for a written scope that lists each application, the protocol used, the logout method agreed for it, and the deliverables for each one. The quote should separate one-time work, such as design, configuration and testing, from any recurring work, such as support or upgrades to authentik. Ask which authentik version the work targets, how upgrades that change logout behavior are handled, and who on the partner side is responsible for each application. Confirm which test environments are used, what acceptance criteria apply, and what happens if an application cannot meet the agreed logout method. DeployOpen works from a written scope before work starts, so ask for the scope, deliverables and timeline in writing before comparing any figures.
How DeployOpen scopes and delivers single logout
DeployOpen plans, implements, tests, documents and supports self-hosted authentik inside your own infrastructure, including single logout across SAML and OIDC applications. Each engagement starts from a written scope that names every application, provider type and logout path before any configuration changes.
How we scope
- Inventory every application, its protocol, and whether it supports SAML or OIDC logout endpoints
- Record which logout channel each application needs, front-channel or back-channel, and why
- Agree the written scope, deliverables and timeline with you before implementation begins
How we build
- Configure SAML and OIDC providers with logout settings and post-logout redirect URIs per application
- Confirm your authentik version and the OAuth2 redirect URI type before setting any Post Logout URI
- Test sign-out with each real application, including sessions that span several applications at once
How we hand over
- Deliver a per-application logout matrix showing protocol, channel, redirect URIs and test results
- Document the verification steps your team can repeat after upgrades or new application onboarding
- Walk your engineers through known limits, including applications that ignore logout requests
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Retest logout paths when you upgrade authentik or change an application's login configuration
- Ask any support provider to confirm response scope and whether logout retests are included
