{"success":true,"data":{"id":"oidc-backchannel-logout-spoof-lure","label":"Fake OIDC Back-Channel Logout 1.0 spoof lure — fake `logout_token` JWT delivered out-of-band; if the relying-party (RP) honors it w/o iss/aud claim verification, the user is kicked back to attacker re-login. Sender NOT on the canonical IdP allowlist (okta.com, auth0.com, microsoft.com, microsoftonline.com, azure.com, login.microsoftonline.com, google.com, accounts.google.com, workspace.google.com, amazon.com, amazonaws.com, awsapps.com, onelogin.com, pingidentity.com, forgerock.com, jumpcloud.com, duo.com, cisco.com, idaptive.com, cyberark.com, sailpoint.com, oneidentity.com). Real IdP back-channel logout notifications never arrive as inbound user-facing email — the logout_token is a server-to-server POST to the RP's `backchannel_logout_uri`. Distinct from R7 PAR / device-code / passkey auth-protocol-param family — this signal is specifically the OIDC Back-Channel Logout 1.0 primitive (openid.net/specs/openid-connect-backchannel-1_0.html). Source: Red-Team R8 multi-agent council S3 (technical-AiTM specialist), Lead consensus C2.","description":"Fake OIDC Back-Channel Logout 1.0 spoof lure targeting enterprise SSO-integrated app users + IT-admin staff. The phish narrative arrives as: \"Your enterprise SSO session received a back-channel logout request. Verify the OIDC logout_token JWT and re-authenticate within 24 hours by clicking below. Failure to complete OIDC sign-out will lock your account,\" or \"Per OIDC Back-Channel Logout 1.0, your relying party received an out-of-band logout_token. Sign in again at the IdP within 48 hours to restore session continuity. Action required.\" OIDC Back-Channel Logout 1.0 (openid.net/specs/openid-connect-backchannel-1_0.html) is a spec where OPs (OpenID Providers) POST a `logout_token` JWT to RPs (relying parties) at the RP's `backchannel_logout_uri` to terminate sessions out-of-band. If the RP fails to validate the `iss` (issuer) and `aud` (audience) claims on the logout_token, attackers can deliver a forged JWT and force the user back to an attacker-controlled re-authentication flow that harvests SSO credentials, MFA codes, and federated session cookies. Real OIDC back-channel logout notifications never arrive as inbound user-facing email — the logout_token is a server-to-server POST to the RP's `backchannel_logout_uri`. Sender NOT on the canonical IdP allowlist (okta.com, auth0.com, microsoft.com / microsoftonline.com / azure.com / login.microsoftonline.com, google.com / accounts.google.com / workspace.google.com, amazon.com / amazonaws.com / awsapps.com, onelogin.com, pingidentity.com, forgerock.com, jumpcloud.com, duo.com, cisco.com, idaptive.com, cyberark.com, sailpoint.com, oneidentity.com). Distinct from R7 PAR / device-code / passkey auth-protocol-param family — this signal is specifically the OIDC Back-Channel Logout 1.0 primitive. Fires when body references OIDC / OpenID Connect / back-channel logout / logout_token / relying party / RP / identity provider / IdP AND back-channel logout / logout_token / out-of-band logout / sign-out / re-authenticate / re-login / sign in again / session (expired/continuity/locked) / verify (the) (logout/JWT) / complete (OIDC) sign-out AND within N hours-days / 24 hours / 48 hours / action required / account (will be) lock(ed/locked out/suspended/disabled) / failure to (complete/verify) urgency. Excludes the canonical IdP domains. Auto-classified as danger via the `-lure` suffix. Source: Red-Team R8 multi-agent council S3 (technical-AiTM specialist), Lead consensus C2.","tier":"danger","category":"scam","isThin":false}}