authentik Shared Signals Framework provider

What the authentik Shared Signals Framework provider sends and when teams need it

The authentik Shared Signals Framework provider sends Security Event Tokens to subscribed OIDC applications when a security-relevant event happens in authentik, such as an MFA device being added or removed, a logout, a revoked session or a credential change. It is typically needed by teams running a business application that keeps a local session alive after the user has signed out, lost access or changed a password somewhere else. Typical examples include a customer portal, an internal tool or a self-hosted application that relies on authentik for sign-in but stores its own session cookie. The provider is an Enterprise feature, so the license must cover it before the design goes further.

The provider is a backchannel component attached to an existing OIDC application, not a replacement for logout configured on that provider. Single logout, including front-channel and back-channel logout for OIDC, still governs how a user's browser session ends at the application they are using. The SSF provider adds a server-to-server signal for events that happen outside that browser flow, such as a session revoked by an administrator or an MFA device removed from another account. Teams should confirm which events their receiving application can act on, because a subscriber that ignores the token gains nothing from it.

Before committing, the team should check three things in the authentik documentation: which signing key the provider uses and how it is rotated, how long events are retained for the configured period, and what the receiving application must validate, including the token signature and the event types it subscribes to. Ask your DeployOpen contact or the vendor to confirm how these settings behave in your version, because retention and key choices affect audit evidence and incident response. The authentik SSF provider documentation is the natural next read for the exact configuration fields.

How the backchannel provider model attaches SSF to an existing OIDC application

The authentik Shared Signals Framework provider is not a standalone integration. It is a backchannel provider attached to an existing OIDC application, so the application's client configuration and its subscription are where planning starts. In practice, the SSF provider sends Security Event Tokens to the applications subscribed to it, and it does so through the application already defined in authentik. Before you attach anything, confirm that the OIDC application signs users in correctly, with the expected redirect URIs, scopes and group or policy bindings. An SSF provider cannot repair a sign-in path that is not working yet.

The receiving application carries most of the risk. Each subscribed application must be able to accept and validate Security Event Tokens, parse the event types it receives, and act on them sensibly, such as ending a session after a revocation event or re-checking access after an MFA device change. Many applications cannot do this out of the box, so each one needs its own review with its owner. Ask the application team what they will do with each event type, whether they have a verified receiving endpoint, and who monitors failed deliveries. Treat the list of subscribers as an access control decision, not a convenience setting.

The exact subscription, delivery and key selection mechanics depend on your authentik version, and the SSF provider behavior should be checked against the current provider documentation in your release before you build. Confirm the event types offered, how subscriptions are created and scoped, which signing key options are available, and how retention is configured. Test each subscribed application end to end in a non-production environment with a real revocation or MFA change, and record the result as evidence for your review.

Provider settings to decide before you enable SSF

This table compares the four configuration decisions a team makes before turning on the SSF provider: the OIDC application it attaches to, the signing key, event retention and the event types each subscriber receives. Read each row as a question to settle with the application owner and your audit team, then confirm the exact options in the documentation for your authentik version.

Decision	What it affects	When it fits	What to confirm
Parent OIDC application	The SSF provider attaches to an existing OIDC application, so the receiving app must already be a working OIDC client with its own client settings.	Choose the application whose sessions and credentials are the ones you need to signal changes for, such as a SaaS or internal app that already signs users in with OIDC.	Confirm in the SSF provider documentation that the chosen application is supported and how the receiving app registers to receive events.
Signing key	The selected key signs each Security Event Token, so the receiver validates events against the matching public key.	Pick a dedicated key for event signing when you want receivers to trust SSF events separately from ID token signing.	Confirm which key sources your version offers, how the receiver fetches the public key and who owns rotation and the rotation schedule.
Event retention period	Sets how long authentik keeps the events it has generated, which determines what you can produce later when an auditor or incident responder asks what was sent.	Set a period that matches your log retention policy and audit evidence requirements, and align it with the event log export you already run.	Confirm the configurable retention options and default in the documentation for your version, and check the period with your compliance owner.
MFA device change events	Signals when a second factor is added or removed, so a subscribed app can act on account takeover risk, such as forcing re-authentication.	Subscribe when the receiving app holds sensitive data or privileged actions that depend on the user's current second factor.	Confirm the exact event type name in the documentation and test that the receiver handles both addition and removal.
Logout and revoked session events	Tells the receiving app that a session has ended or been revoked, so it can end its own local session in step with authentik.	Subscribe when the app keeps its own session state and must not keep a user signed in after an authentik logout or revocation.	Confirm which logout and revocation events are emitted and whether the receiver must acknowledge them or handle them idempotently.
Credential change events	Signals password or credential changes so the receiving app can revoke tokens or require re-authentication.	Subscribe for apps that cache credentials, issue long-lived tokens or depend on the user's password state.	Confirm which credential event types exist for your version and whether they cover the authenticators your users actually use.
Subscribed event types per application	Each subscription should carry only the events that receiver acts on, which limits data sent to third parties and reduces noise.	Start with the smallest set that addresses a named risk for that application, then widen it after testing.	Confirm in the documentation how subscriptions are scoped per receiver and how to change them without disrupting delivery.

Which authentik edition and licence fit SSF plans

Organizations running the Open Source edition get the core authentik code under the MIT license (SPDX: MIT), which covers the server, worker and most providers. The Shared Signals Framework provider is an Enterprise feature, so it is not available on this edition, and the code for enterprise features lives in the authentik/enterprise/ directory under a separate enterprise license defined in that directory. The authentik pricing page lists the Open Source edition as free, with support through the community Discord only.

No SSF provider: Event delivery to subscribed applications cannot be configured on this edition, so logouts and credential change events must be handled by other means.
Community support only: The pricing page lists the community Discord as the support channel, with no ticket-based support.
Licence split: Read the MIT licence for core code and the enterprise licence in authentik/enterprise/ before you assume a feature is free to use.
Migration path: Moving to Enterprise later means a licence purchase and a configuration review, not a reinstall.

Confirm with your own team whether event-driven logout is a hard requirement. If it is, this edition does not meet it.

Setting up the authentik Shared Signals Framework provider in a test environment

This sequence takes a test authentik instance from licence and version checks to a verified flow in which logouts, revoked sessions and MFA device changes reach a subscribing receiver and are recorded.

Confirm licence and supported version
The platform or security lead confirms that the test instance runs an authentik release supported under the project's security policy and that the Enterprise licence required for the Shared Signals Framework provider is active. The SSF provider is an Enterprise feature, so an Open Source-only instance cannot complete the remaining steps. Check the installed version against the security policy and the releases page, and record the version number in the test plan. The step is done when the licence status and version are written down and the instance is confirmed as the one to test against.
Create or select the receiving OIDC application
The identity engineer creates a new OIDC application in authentik for the test receiver, or selects an existing test application. The SSF provider attaches to an OIDC application rather than standing alone, so the application's client settings, redirect URIs and assigned users must be correct before events are sent. Use a non-production application and a dedicated test user so that later events cannot affect real accounts. The step is done when the application appears in the applications list, can complete a sign-in with the test user, and its provider settings are saved.
Add the SSF provider and attach it to the application
In the authentik admin interface, the identity engineer adds a Shared Signals Framework provider and binds it to the OIDC application created in the previous step. The SSF provider works as a backchannel provider, so it runs alongside the application's existing OIDC configuration and does not replace it. Field names and menu locations change between releases, so confirm each screen against the SSF provider documentation before saving. The step is done when the provider is saved, shows as attached to the correct application, and the application still signs the test user in.
Select the signing key
The security engineer selects the key that signs the Security Event Tokens the provider emits. Choose a key that the receiver can verify, and record which key was chosen, where its public part is published, and who holds the private material. Ask the platform team how signing keys are created, rotated and stored in the target environment, because a receiver that caches the wrong key will reject every event. The step is done when the key is selected, the receiver has the matching verification material, and the choice is documented in the test notes.
Set the event retention period
The platform lead sets how long the provider keeps emitted events, using the retention setting in the SSF provider configuration. Retention determines how far back the team can review what was sent and whether delivery succeeded, so the value should match the evidence period that the test is meant to support. Confirm the retention options and their units in the SSF documentation, and note in the test plan what the reader's own audit or incident response process requires. The step is done when the retention value is saved and recorded alongside the other provider settings.
Add the subscribing receiver
The integration engineer registers the subscribing receiver with the SSF provider, so authentik knows where to deliver events and which event types the receiver accepts. Use a test receiver endpoint that the team controls and can inspect, such as a logging service, and confirm that it can reach the authentik instance over the network path used in the test environment. Event types should match the three scenarios in the check step. The step is done when the subscription is saved and the receiver shows as active or subscribed in the provider configuration.
Trigger and verify test events
The test lead signs in with the test account and performs three actions: a logout, a session revocation for an active session, and the addition or removal of an MFA device. After each action, confirm that the receiver logged a Security Event Token for that action and that authentik's event log recorded the matching entry. Record the time of each action, the event type received, and any delivery errors. If an event does not arrive, check the receiver's accepted event types, the signing key and network reachability before retrying. Consult the SSF documentation for the exact event type names and any screens that differ from this sequence. The step is done when all three events are received and recorded, and the results are written into the test report.

Security risks in signing keys, event retention and receiving applications

An SSF provider is only as trustworthy as the key that signs its events, the applications that verify them, and the admin accounts that can change either. The cards below cover where those risks sit and what to verify in your environment before subscribers depend on the events.

Protecting and rotating the signing key

The SSF provider signs each Security Event Token with a key you select, so that key is the root of trust for every event a subscriber receives. Anyone who can read the private key can forge logout or credential-change events, and anyone who can swap the key can break verification for every subscriber at once. Confirm where the key is stored, who holds read access to it through authentik and the host, and what your rotation procedure looks like, including how subscribers receive the new public key.

Trust placed in event authenticity

A receiving application acts on an event such as a revoked session or a removed MFA device. It should act only after it has verified the signature and the expected issuer and audience. An application that accepts unsigned or unverified tokens turns the SSF channel into an injection path. Test that each subscriber rejects a token signed with a different key and a token addressed to another receiver, and record which of these checks the application's own code or library performs.

Retention settings and the evidence they keep

The SSF provider can retain events for a period you configure. Retention decides what evidence exists when an incident review asks whether a logout or credential change was sent and when. Short retention limits storage but may leave no record for a late investigation, while long retention keeps more personal data about user activity. Set the period with your records policy and legal team, and confirm that events you need for audit are also captured in your central log store.

Applications that ignore or drop events

Sending an event does not prove the application ended the session. If a subscriber is down, misconfigured, or silently discards events, a user who was removed or had a session revoked can keep working inside that application. Ask each application owner how it handles failed deliveries, whether it logs receipt, and how long a stale session can survive. Test with a revoked session on a real subscriber and confirm the application terminates it within the time your policy allows.

Admin access to SSF provider settings

Whoever can edit an SSF provider can add a subscriber, change the signing key, or alter which events are sent. Those changes are as sensitive as edits to the OIDC application the provider is attached to. Limit edit rights for providers to a named admin group, require that changes go through your normal change process or blueprint review, and check the event log for provider edits. Confirm which roles in your authentik instance can reach the provider pages.

Verifying that events arrive and drive the right action in each application

Start the verification plan with a test matrix: one row for each event type the SSF provider sends (MFA device added or removed, logout, revoked session, credential change) and one column for each subscribed application. In each cell, record the expected action in that application, such as ending the local session, forcing re-authentication, or ignoring the event because the application has no matching behavior. Run each event against a test user, then check the application's own logs and session state, not only the authentik event log. Many applications accept a security event token without acting on it, and only testing against the real application shows which events change behavior. Confirm the event handling for each application with its vendor documentation before you write the expected results, because this behavior belongs to the application, not to authentik.

Add three checks to every cell. First, confirm the receiving application revokes or refreshes the session on receipt, and measure how long the session stays active afterward. Second, confirm the application validates the event signature against the correct key from the SSF provider's signing configuration, and rejects an event signed with a key it does not trust. Third, confirm retained events can be found during an investigation: query the stored events for the test user and check that the event identifier, timestamp and subject match what the application received. Retention is set in the provider configuration, so confirm the retention period with your team before you rely on it for an investigation. Keep the raw event payloads and the application logs for each run as evidence, with the authentik version, the provider settings and the test date recorded alongside them.

Repeat the full matrix after every authentik upgrade, after any change to the signing key, and after each application upgrade, because each can change event formats, key discovery or session handling. The authentik documentation describes the provider model, and the authentik SSF provider documentation is the right reference for confirming field names before you write test scripts. DeployOpen can plan and run this matrix for each engagement, covering the applications you subscribe, their session behavior and the evidence your audit team expects. Ask for the test scope, the applications included and the evidence format in the written scope before work starts, since the effort depends on how many applications react differently to each event.

Limits to confirm before you depend on SSF events

The SSF provider is an Enterprise feature that depends on the authentik version, the receiving application and your license terms. Each card below names one point to confirm, with the vendor page, documentation or test that settles it before you build a dependency on these events.

Emitted event types by version

The supplied documentation lists events such as MFA devices added or removed, logouts, revoked sessions and credential changes. Confirm against the release you run which of these your flows actually produce, and whether any event you need is missing. Trigger each one in a test tenant and capture the Security Event Token to see its exact contents.

Apple Business Manager scope

Confirm whether Apple Business Manager or other Apple-side integrations fall inside the SSF scope for your deployment. Ask the vendor how any such integration is configured, which side holds the signing keys and how events reach the Apple service. Do not assume coverage from the general SSF page. Treat the answer as unconfirmed until it is written down in the vendor's own documentation or support response.

Receiver support for SET

An SSF provider only helps if the receiving application accepts Security Event Tokens at the endpoint you configure. Check the receiver's documentation for SET validation, the signing algorithm it expects and how it handles events it does not recognize. Run an end-to-end test that revokes a session in authentik and confirms the application ends that session.

Supported security fix versions

The authentik security policy lists 2026.5.x and 2026.8.x as the versions receiving security fixes, and security releases are announced at least 24 hours in advance. If you run a version outside those lines, a fix to SSF handling may never reach you. Confirm your running version against that policy and plan upgrades on a schedule you can meet.

Enterprise license coverage

SSF is an Enterprise feature, and the pricing page lists Enterprise at a per-user monthly rate plus a per-external-user rate. Ask for a written quote that counts your internal and external users, and confirm whether the SSF provider is covered at the tier you buy. Enterprise Plus extras such as dedicated support are separate and recurring. Also check the enterprise license terms in the enterprise directory.

How much effort and cost does an authentik SSF rollout involve?

What drives the cost of an authentik SSF rollout?

The main drivers are the number of subscribed applications, the event types each receiver needs, how ready each receiver is to accept Security Event Tokens, and how deeply the change is tested. Each subscribed application adds its own configuration, verification and sign-off, so a rollout to three applications is a different piece of work from one to thirty. Event types add scope because each one needs a defined trigger, a receiver action and a test case. Receiver readiness matters most: an application that cannot validate tokens or handle a revoked session needs development work on its side before authentik can help. Testing depth, including negative cases and failure handling, is the last major driver. Ask for the effort split between configuration, receiver integration testing and documentation.

Can an in-house team set up authentik SSF without outside help?

Yes, a team with OIDC experience and access to the authentik administration interface can attach an SSF provider to an existing OIDC application and configure its keys and retention. The harder work sits outside authentik: confirming each receiver validates Security Event Tokens, deciding which events each application should act on, and proving that a revoked session really ends access. Teams that have not run backchannel event delivery before often underestimate those receiver-side tests. The SSF provider is an Enterprise feature, so the licence decision comes first. Confirm the licence scope and the feature's current status with authentik before planning.

What does the customer need to provide for an SSF engagement?

The work depends on access and people more than on tooling. Expect to provide named application owners who can confirm expected behaviour and test each receiver, a test tenant or staging environment for each subscribed application, and an authentik Enterprise licence for the SSF provider. Change windows are needed because enabling event delivery and revoking sessions can affect live users. Someone must also own the signing key choice and the event retention period, since those decisions carry audit and security implications. Agree these responsibilities in the written scope so that delays on the customer side are visible.

Which authentik licence does SSF require, and what does it cost?

The authentik Shared Signals Framework provider is an Enterprise feature, so it is not available in the Open Source edition. The authentik pricing page lists Enterprise at $5 per user per month billed annually, plus $0.02 per external user per month. It also lists Enterprise Plus starting at $20k annually, with dedicated support and SLAs. Confirm with authentik which edition covers your user counts and whether your deployment needs any Enterprise Plus extras. Licence cost is recurring and separate from the one-time implementation work.

How long does a scoped SSF rollout take for a given number of applications?

The duration is set by the written scope, not by a general rule. Duration grows with the number of subscribed applications, the event types in each subscription, and how many receivers need code changes before they can accept events. A rollout that only configures authentik and tests one receiver is much shorter than one that includes receiver development, staged testing and change windows across several applications. Ask for a timeline per application, a list of dependencies on application teams, and the points where your sign-off is required. Any timeline should be tied to a defined scope in writing.

Does SSF replace single logout for authentik applications?

No. SSF sends security events to subscribed applications, such as logouts, revoked sessions, MFA device changes and credential changes, over a backchannel. It complements single logout rather than replacing it. Single logout covers how a user's browser sessions end across applications, and each application still needs its own logout behaviour. Plan both together, test them against real applications, and confirm which applications rely on which mechanism before deciding what to switch on.

What should a written quote for an SSF rollout include?

A useful quote lists the applications in scope, the event types each one subscribes to, and the receiver work included or excluded. It should state the testing approach, including which environments are used and how failures are handled. It should name the deliverables, such as configuration records, test results and runbook notes, and the customer responsibilities described above. Ask how change windows, retries and post-go-live support are priced, and whether signing key rotation and event retention changes are included. Separate one-time implementation costs from any recurring support, and request the licence assumptions in writing. Contact DeployOpen to discuss the scope before a quote is prepared.

How DeployOpen scopes, delivers and supports SSF work

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, including authentik. For the Shared Signals Framework provider, the work starts with a written scope that names the applications, event types and signing approach before any configuration begins.

How we scope

The written scope lists each OIDC application that will subscribe to security events from authentik.
It names the event types in scope, such as logouts, revoked sessions, MFA device changes and credential changes.
It records the signing key choice, event retention period and where the Enterprise license requirement is confirmed.

How we build

We attach the SSF backchannel provider to each existing OIDC application, one application at a time.
We test each subscriber against sample events in a non-production authentik instance before enabling live traffic.
We document each subscriber's receiver configuration, key handling and expected event behavior as part of the build.

How we hand over

Handover includes configuration records, a subscriber inventory and the runbook for rotating signing keys.
Your team receives test evidence showing which events each application received and how it responded.
We walk your operators through verifying event delivery and reviewing retention settings with your own team.

How we support

Ongoing support for authentik and its SSF configuration is available as a retainer, scoped in writing.
Support covers reviewing authentik upgrades for changes that affect SSF providers and subscribed applications.
Continuous testing of subscriber endpoints can be added to a retainer if your security program requires it.