Skip to main content

SameSite cookie e SSO

A partire da lunedì 17 Febbraio 2020, Google distribuirà una versione del browser Chrome, la 80, che forzerà il valore dell'attributo SameSite per i cookie. SameSite, che può assumere i valori Strict, Lax e None, regola l'invio dei cookie nelle richieste dirette a URI esterne al sito che si sta visitando. Gli autori del draft che definisce l'attributo SameSite (draft-ietf-httpbis-rfc6265bis) definiscono same-site le richieste HTTP in cui il dominio della URI di destinazione è lo stesso della URI di origine. Altrimenti le richieste sono definite cross-site.

L'effetto è che qualunque link o contenuto embedded relativo a siti diversi da quello di origine ricade nella categoria cross-site. A seconda del valore dell'attributo SameSite ci sarà una politica diversa nell'invio dei cookie per le richieste "cross-site", ovvero:

  • con valore Strict, nessun cookie verrà inviato;
  • con Lax, verranno inviati i cookie per le richieste che sono visibili nella barra di navigazione (top level navigation) e che utilizzano metodi HTTP safe: in questo contesto, non POST, ma GET.
  • con None, verranno inviati tutti i cookie.

Quando l'attributo SameSite per un cookie non è specificato, Chrome 80 lo forza ad assumere il valore Lax, quindi prevenendo l'invio di cookie tramite richieste HTTP POST. Nel contesto dell'autenticazione federata, questa limitazione bloccherà l'invio dei cookie nel caso delle richieste inviate via HTTP POST Binding, e quindi in alcuni casi romperà il SingleSignOn (SSO). In pratica sarà necessario autenticarsi anche se lo si è già fatto per accedere ad un altro Service Provider.

Ci sono però un paio di buone notizie. La prima è che Chrome 80 introdurrà la "feature" in modo graduale, e all'inizio (ma non si sa esattamente per quanto tempo) permetterà
l'invio dei cookie nelle richieste HTTP POST "cross-site" originate entro 2 minuti dalla visita del sito principale. Ciò permetterà il funzionamento della quasi totalità dei casi d'uso, anche se è bene ricordare che si tratta di una misura a tempo. L'altra buona notizia è che nelle federazioni di identità della ricerca e dell'educazione di solito si usa il binding HTTP redirect, che prevede l'uso di HTTP POST solo per la SAML Response, limitando di molto i danni sul SSO.

In ogni caso, gli sviluppatori dei software di autenticazione federata sono già al lavoro per il futuro, quando l'attributo SameSite sarà ancora più determinante. Per saperne di più vedi:

Come Servizio IDEM GARR AAI continueremo a monitorare la situazione e vi terremo informati.

Aggiornamenti tecnici