-
Notifications
You must be signed in to change notification settings - Fork 94
Description
The Nginx OpenID Connect module’s front-channel logout implementation (at the /front_channel_logout endpoint) currently requires both the sid (session ID) and iss (Issuer) query parameters to be present in logout requests, per the OpenID Connect Front-Channel Logout 1.0 spec. However, Microsoft Entra ID does not fully adhere to this spec, it calls the front-channel logout with only a sid param and omits the iss. For example, a logout request from Entra ID might look like:
GET /front_channel_logout?sid=007e3899-e104-731f-b675-0617c1f2dd72 HTTP/2.0
The issuer (iss) identifier is required because a sid value is only guaranteed to be unique within the context of a particular OP.
This is a known deviation from the OIDC spec. In fact, this behavior has been observed and reported in the community as far back as 2020 when Azure AD first added front-channel logout support.
Because this njs implementation currently expects both sid and iss for front-channel logout, a logout request from Microsoft Entra ID will not be processed as intended. Specifically, when the module’s /front_channel_logout endpoint is hit with only a sid query parameter and no iss, the request is considered invalid:
error: Missing iss parameter in front-channel logout request
Considerations and possible workarounds:
Given that Entra ID is unlikely to change this behavior in the near future, we need to consider how to handle this discrepancy. One obvious approach is to relax the requirement on our side and accept a logout request with only a sid. However, we have some security and correctness concerns about relying on sid alone without the iss:
- The FC logout spec explicitly requires iss for a reason -
sidis not guaranteed to be globally unique across different OPs - Front-channel logout requests are delivered via the user agent (browser) (often in a hidden iframe initiated by the IDP). The UA will not send the session cookie with this cross-site iframe request (especially with modern default SameSite cookie settings). This means we cannot rely on
auth_tokencookie to identify the session.