backchannel logout spec doesn't have requirement that 'sid` in id_token & logout_token match

Issue #1176 resolved
Joseph Heenan created an issue says:


OPTIONAL. Session ID - String identifier for a Session. This represents a Session of a User Agent or device for a logged-in End-User at an RP. Different sid values are used to identify distinct sessions at an OP. The sid value need only be unique in the context of a particular issuer. Its contents are opaque to the RP. Its syntax is the same as an OAuth 2.0 Client Identifier.

I expected this to say “the sid value MUST match that in the id_token” or something along this line. To some extent it’s currently left to the reader to realise the values must be the same.

Comments (5)

  1. Filip Skokan

    Since the id_token passed to rp-initiated logout is a hint I don’t think we can expect the logout token’s sid to always match what the RP then receives in the backchannel logout request. The OP can ignore the id_token_hint when it’s no longer one related to the end-user session and continue without it, albeit now knowing the client and able to verify the post_logout_redirect_uri.

    Furthermore, when a client receives a logout token out of the blue (because e.g. it wasn’t the one initiating the rp-initiated logout request) then there’s not much to match against, the RP will search its records for a session match based on the sid or sub and drop them (or put them on a “revoked” list for when they re-appear).

  2. Joseph Heenan reporter

    I’d forgotten there were multiple id_tokens in play. I guess I meant “the sid value MUST match that in an id_token previously issued by the OP”.

  3. Filip Skokan

    On the RP? MUST? Maybe. Consider my OP just puts the sid in there all the time. But my RP policy is to drop all sessions for a user regardless of the sid I receive. SHOULD describes that scenario better imho.

  4. Log in to comment