RP-initiated logout is refused for good (invalid_token: sid) once the user's SSO session has been replaced

Aperta
  • Qualcosa non va?
#20,058 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
43/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java, spring
Ambito
authentication, backend-api-design

Direzione di ricerca

Start with OidcLogoutAuthenticationProvider and JwtGenerator in oauth2/oauth2-authorization-server, then trace the logout validation and refresh-token ID token generation described in the issue. Reproduce the flow with an earlier ID token after the user's session is replaced, and check existing logout tests for coverage. Done means logout accepts the same user's earlier sid while still rejecting an ID token whose sub belongs to another user.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

status: waiting-for-triage type: bug

Describe the bug

When a user's session at the authorization server is replaced by a new one (a new login, or a session restored by remember-me), RP-initiated logout fails for every client that still holds an ID token from the earlier session. /connect/logout answers 400 with invalid_token / OpenID Connect 1.0 Logout Request Parameter: sid instead of redirecting to post_logout_redirect_uri. The client is never told to end its own session, so the user stays signed in there.

A refresh doesn't help, because the refreshed ID token carries the same old sid. That client can't log out any more until it goes through a new authorization code flow.

Two parts of the authorization server combine here:

  1. JwtGenerator, refresh_token grant: copies sid from the previous ID token. This was added in spring-projects/spring-authorization-server#1224 (SAS 1.1.1), since a back-channel refresh has no browser session to take a sid from: 
    String sidClaim = currentIdToken.getClaim("sid");
if (sidClaim != null) {
    claimsBuilder.claim("sid", sidClaim);
}
  2. OidcLogoutAuthenticationProvider: when the principal is authenticated and the current session is in the SessionRegistry, it requires sid to equal the hash of that session: 
    String sidClaim = idToken.getClaim("sid");
if (!StringUtils.hasText(sidClaim) || !sidClaim.equals(sessionIdHash)) {
    throw createException(OAuth2ErrorCodes.INVALID_TOKEN, "sid");

So as soon as the session is replaced, every outstanding ID token carries a sid that can never match again, even though sub is the user who is signed in.

It goes unnoticed in many setups, because the check is skipped when nobody is signed in at logout (an expired session) and when the session isn't in the registry (another replica with the default in-memory SessionRegistry; that may be what spring-projects/spring-authorization-server#1547 saw). It shows reliably with remember-me, or with several clients sharing one SSO session where one of them makes the user sign in again.

To Reproduce

Single instance, default SessionRegistry, a client with openid and a registered post_logout_redirect_uri:

  1. Sign in as user U (session A), run the authorization code flow, and keep the ID token (sid = hash(A)).
  2. Replace the session for the same user U: sign in again, or restore through remember-me (session B), and run the authorization code flow again, so that B is in the SessionRegistry.
  3. In session B, call GET /connect/logout?id_token_hint=<ID token from step 1>&post_logout_redirect_uri=<registered>.

Actual: 400, invalid_token, parameter sid. Logs show OAuth2 authentication failure: OpenID Connect 1.0 Logout Request Parameter: sid.
Same result with an ID token obtained by refresh in step 1, at any later time.

Expected behavior

The logout succeeds and ends the session the browser has (B), as long as the other checks pass: the ID token is known, aud/client_id match the client, post_logout_redirect_uri is registered, and sub is the signed-in user. An ID token of another user must still be refused, which the sub check already does.

The OIDC RP-Initiated Logout spec doesn't require the sid comparison. When the OP isn't sure the request comes from the signed-in user, it should ask the user whether to log out, not return an error.

Possible fixes

Any of these would do:

  • treat a sid that doesn't match but belongs to the same sub like a request without a session id, i.e. skip the session comparison;
  • make the session check pluggable (e.g. a setSessionValidator, or run the authenticationValidator after the identity checks with the session information in the context);
  • or at least make OidcLogoutAuthenticationProvider non-final.

Today the only way out is to wrap the provider through OidcLogoutEndpointConfigurer.authenticationProviders(...). On a sid failure, which can only be recognised by the error description, the wrapper calls it again with a token that has no session id. setAuthenticationValidator can't help, because it runs before the identity block.

Versions

Reproduced with Spring Authorization Server 1.5.8 (Spring Boot 3.5). The same code is on main of spring-security, in oauth2/oauth2-authorization-server (OidcLogoutAuthenticationProvider, JwtGenerator, both @since 7.0).

Related: spring-projects/spring-authorization-server#1224 (sid missing after refresh, fixed by copying it), spring-projects/spring-authorization-server#1547 (same error with several replicas, closed as invalid), #15509 (client keeps the original ID token after refresh).

Lingua principale
Java
Stelle
9.7k
Fork
6.4k
Merge medio
3h 11m
PR unite (30g)
19

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di spring-projects/spring-security

Tutte le issue di spring-projects/spring-security

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.