Single sign off con OAuth 2

Question

Abbiamo appena discusso del comportamento di accesso e disconnessione quando si utilizza OAuth 2. Supponiamo di avere due webapp A e B utilizzando un provider OAuth O (creato utilizzando lo stack spring-security-oauth2).

Quando si desidera eseguire il login per A si ottiene reindirizzato a O, immettere le credenziali, ottenere una sessione lì O, reindirizzato ad A con un token di accesso e una sessione viene creato sul A pure.

Ora, quando si desidera eseguire il login per B si ottiene reindirizzato a O, arrivare direttamente rimandati con un token a B perché avete ancora un sesison valido O e una sessione viene creato B così (senza dover inserire le tue credenziali di nuovo).

Questo risolve il nostro unico segnale sul problema.

Un requisito è ora, che quando logout da AoB si è connessi fuori sempre da entrambi/tutte le applicazioni (single sign off).

La nostra idea è:

• valorizzare il token di accesso con l'attuale id di sessione
• Se app A o B vogliono disconnettere un utente, lo reindirizzamento alla pagina di logout di O
• Se l'utente viene disconnesso da O, tutti i token di accesso appartenenti alla sessione corrente su O vengono rimossi e l'utente viene reindirizzato a A o B
• La sessione sulla A o B viene distrutta
• A e B controllo per la validità della loro token di accesso OAuth su ogni richiesta e distruggere la loro sessione se il token non è più valida

Queste è un caso d'uso valido per OAuth 2? Come implementeresti il ​​single sign off in modo diverso?

Answer 1

Il motivo per cui non esiste una risposta categorica a questa domanda è che tutto dipende dalla preferenza dell'utente per l'esperienza utente e dalla misura in cui ci si fida e/o si ha il controllo delle app e dei server.

Penso che ci siano diversi modi in cui potresti farlo e la tua proposta è sicuramente lavorabile. Lo criticerei solo perché a) stai usando un token OAuth come token di sessione, e non sono realmente la stessa cosa, e b) il "controllo della validità del loro token di accesso OAuth su ogni richiesta" è un un po 'vago, e ho il sospetto che la UX potrebbe soffrire.

In generale non è sempre consigliabile disporre di un unico accesso da un sistema di app client OAuth2: gli utenti potrebbero credere di essere connessi a sistemi separati, che si verificano per autenticarsi in modo conveniente per loro, e in realtà non vogliono un esperienza di single sign-off (ad es. se mi disconnetto da un'app per Facebook fornita dall'utente, non mi aspetto di essere disconnesso dalla mia timeline).

Se si do è necessario un unico accesso e tutte le app si trovano nello stesso dominio è possibile avere loro condividere un cookie di sessione nell'ambito del dominio che condividono. Questo è pericoloso se altre app condividono lo stesso dominio e potrebbero non voler partecipare al comportamento di single-sign-on/off, o se non ti fidi di loro per mantenere segreti i cookie.

Con sessione primaverile si può essere più sofisticata e condividere una sessione di token solo tra le applicazioni di cui ti fidi (dato che solo fornire loro l'accesso al negozio di sessione). Probabilmente sarebbe abbastanza efficiente, e potrei farlo in quel modo nella tua posizione, se avessi il controllo di tutti i pezzi mobili.

Potrebbe aiutare a guardare la OpenID Connect Session Management Spec per vedere se ci sono tutte le idee lì. Esiste sicuramente il concetto di token di identità (distinto dal token di accesso). Penso che suggeriscano di fare i controlli di validazione nel browser con script in un iframe, che sembra terribilmente brutto, ma forse non c'è davvero un modo migliore. Se ti piace questa idea, potresti magari fare la stessa cosa con i normali cookie di sessione (non è necessario probabilmente l'OIDC completo).