Logout notifications
M7 supports front-channel and back-channel logout for applications that have participated in a root SSO login session. Both discovery documents advertise these capabilities, verified on 2026-09-20 at 02:58:25 UTC. A notification tells your application to end the matching local session; your receiver is responsible for carrying out that action.
What triggers a notification
| Action | Front channel | Back channel |
|---|---|---|
| Confirmed SSO end-session logout, including an individual remembered-account × | Yes, for registered participating apps | Yes, for registered participating apps |
| Explicit logout × in the account chooser | Yes | Yes |
| Revoke a root session through account session management | No; the target browser may be absent | Yes |
| Ordinary account selection, switching, re-login or session replacement | No | No |
Notifications follow confirmed revocation of the selected root and its token family. They do not run merely because the logout page is opened. Expiry, password changes and other implicit invalidations are outside these notification triggers. Log Out These concerns the matching remembered sessions in that browser/context; it is not an account-wide, all-devices operation.
Applications join the notification set at successful OpenID Connect
authorization-code pickup at /token. Only pickups made after this feature was
installed are tracked. Sign in again before testing an older session. Device
grants, client credentials and independent token families are not added to this
browser-root set.
ID tokens carry a stable sid identifying the original root login; refresh
rotation preserves it. Store it with the validated issuer and your application's
local session. The local account-management record ID, ID-token jti, and
root sid are different identifiers. Several applications can share one root.
Register receiving URLs
Use Dynamic Client Registration or application management.
| Field | Meaning |
|---|---|
frontchannel_logout_uri |
HTTPS browser receiver. Scheme, host and port must match a registered sign-in redirect URI. |
backchannel_logout_uri |
HTTPS server receiver. A different host or port is permitted. |
frontchannel_logout_session_required |
Standard registration boolean, default false; declares that the receiver requires iss and sid. |
backchannel_logout_session_required |
Standard registration boolean, default false; declares that the receiver requires sid. |
Both URLs allow static query parameters, must be at most 2,048 characters, and cannot contain credentials or fragments. Configure only receivers you operate. Current registration is used at delivery time; removing a URL disables that channel. A true session-required flag requires its corresponding URL.
M7 always sends sid on both channels, and iss on the front channel.
False or omitted session-required flags do not suppress these values or disable
delivery. User.M7 therefore presents the two URL fields without session-ID
checkboxes. Its Client → Logout tab appears when editing an existing application
and has a separate Update Logout Settings action. Post-logout redirect URIs
remain under General: they control the final browser destination, not receivers.
Saving configuration alone does not send a notification or end a session.
Front-channel receiver
M7 loads each registered URL in a hidden iframe with iss and sid query
parameters. For example:
GET https://app.example.com/logout/front?iss=https%3A%2F%2Fsso.user.m7.org&sid=ROOT_SESSION_ID
The receiver should check the exact trusted issuer and associate the sid
with its own session before clearing that session. It must be usable within
an iframe from the provider origin. Browser cookie and framing policies can
prevent access to local state; front-channel logout is not a reliable way to
terminate sessions on another device.
M7 waits for frame completion or a 2.5-second limit, then continues to the validated return destination. A Continue link supports manual navigation. Frame completion is not proof that the application cleared its cookies.
Back-channel receiver
M7 sends an HTTPS POST with Content-Type: application/x-www-form-urlencoded
and one form field, logout_token. The request does not depend on browser
cookies or a current browser login.
The token is a signed JWT with protected-header typ: logout+jwt. It contains:
| Claim | Value |
|---|---|
iss |
Canonical SSO issuer, https://sso.user.m7.org |
aud |
Receiving application's public OAuth client ID |
sub |
Subject associated with the participating root |
sid |
Original root session identifier |
iat, exp |
Issue time and expiry, with a 120-second lifetime |
jti |
Unique notification identifier |
events |
An object containing http://schemas.openid.net/event/backchannel-logout with an empty object value |
There is no nonce. The current registered ID-token signing algorithm also
applies to Logout Tokens. Required ID-token response encryption applies too:
decrypt the compact JWE, then validate the inner signature and claims. See
response encryption. This artifact is never an access
or refresh credential and must not be accepted for sign-in or API authorization.
A receiving application must validate the signature using trusted issuer keys or the configured HMAC secret, supported algorithm, issuer, audience, token type, time claims, logout event and session association. Reject malformed or inappropriate tokens and handle duplicates safely. Do not trust claims from an unverified decoded token. On accepted processing, return HTTP 200; use HTTP 400 for an invalid Logout Token. An already-ended matching session can be acknowledged without requiring the user to return first.
Delivery uses public HTTPS destinations, TLS verification and no redirects. Requests have a one-second connection timeout and three-second overall timeout, with bounded concurrency. Notification failure does not restore a revoked root. Explicit browser logout makes a best-effort attempt without a persistent retry queue. Account session revocation separately records pending work for service reconciliation; applications must tolerate a repeated notification. HTTP success proves receiver acceptance, not application-side invalidation.
Current M7 Web/PHP SDK boundary
The updated source installed in User.M7 and Drop exposes:
GET /m7_sso_session/frontchannel-logout
POST /m7_sso_session/backchannel-logout
The front receiver clears that browser's SDK cookies. It does not yet match
incoming sid against a stored local session. The back receiver validates the
notification and returns ok; it does not invalidate application sessions.
Application-side enforcement and further SDK tuning are separate work.
The current Web/PHP verifier supports RS256/RS512 through OpenSSL and Ed25519
when the optional ext-m7crypto runtime is available. With no
M7_ID_TOKEN_SIGNED_RESPONSE_ALG setting it verifies an incoming supported
algorithm. An explicit setting additionally pins that algorithm. Unsupported
algorithms or missing native support produce algorithm_unsupported; a
supported algorithm that differs from an explicit pin produces
algorithm_mismatch. Signature and claim validation always remain required.
Do not infer receiver support from the wider token SDK's algorithm list.
Receiver failures return a bounded reason and correlation ID. The sender can record the recognized reason and ID alongside the HTTP status; use them to correlate receiver logs without recording tokens or arbitrary response bodies. These installed-source capabilities do not imply that previously published immutable SDK archives include the receivers or their latest fixes.
Integration check
- Deploy a compatible receiver and save its URL on the correct client.
- Complete a fresh OpenID sign-in to that application to record participation.
- Explicitly log out one remembered account and check that only its matching application session is ended by your receiver.
- Test the browser's grouped logout and the chooser × separately. Account switching should not generate notifications.
- Test own-session revocation from another session: expect back-channel delivery, with no front-channel frame.
- Check invalid-token rejection, duplicate receipt and unavailable-receiver handling. A 200 from the current SDK back receiver tests receipt only.
Protocol references: OpenID Connect Front-Channel Logout and OpenID Connect Back-Channel Logout.