Utente autenticato in movimento per un servizio diverso

Questo è molto simile a un servizio Single Sign-On, tranne che di solito non controlli tu stesso tutti i servizi (invece, uno di questi è controllato dal provider SSO, come Facebook o Google). Puoi guardare OAuth2 per alcune idee su come SSO è più comunemente implementato, ma è onestamente eccessivo per uno scenario in cui controlli entrambi i servizi.

Supponendo che tu controlli entrambi i servizi e che le chiamate tra di loro siano sufficientemente economiche, una soluzione semplice è quella di avere una di queste fonti di verità sull'identità, quindi service2 controlla semplicemente il servizio1 per la conferma di chi è l'utente e cosa possono fare (quali sono i loro dati segreti, quanti crediti hanno, ecc.), senza memorizzare alcuna di tali informazioni. Il problema è quindi collegare la sessione dell'utente attraverso entrambi i servizi.

Puoi utilizzare l'approccio URL:

1. service1 genera un token casuale sicuro monouso e lo passa a service2 nell'URL
2. service2 invia quel token a service1 attraverso un canale diretto
3. service1 risponde con un identificativo di sessione per la sessione dell'utente e anche qualsiasi altro servizio dati2 vorrà sicuramente
4. service2 imposta l'identificativo di sessione da service1 come identificativo di sessione sul client (probabilmente in un cookie sicuro) e facoltativamente memorizza i dati richiesti nel proprio stato di sessione per quella sessione

In alternativa, è possibile utilizzare CORS (Cross-Origin Resource Sharing), che è un modo per un browser Web di violare la politica della stessa origine in modo controllato tra siti che si fidano l'uno dell'altro (e sono eventualmente controllati dallo stesso entità). CORS ti consente di creare XMLHttpRequest o di recuperare le chiamate tra le origini e vedere le risposte. Un esempio potrebbe essere simile a questo:

1. service2 riceve una richiesta da un nuovo utente che non ha una sessione o un utente la cui sessione è scaduta
2. service2 risponde con una pagina contenente uno script che effettua una richiesta CORS, con autenticazione, a service1
3. Supponendo che l'utente sia connesso al servizio1, service1 accetta la richiesta CORS e risponde con un token casualmente sicuro monouso
4. Lo script sul lato client invia questo token a service2
5. service2 invia questo token a service1 tramite un canale back diretto
6. service1 verifica il token e invia un identificatore di sessione a service2, ecc.

Questo schema equivale a passare il token nell'URL, con due eccezioni:

• Il token non viene mai inviato nell'URL e pertanto è molto meno probabile che finisca da qualche parte, non dovrebbe come un log del server o una cronologia del browser.
• L'utente può accedere direttamente a un URL di servizio2 senza fare clic su un collegamento speciale da service1, a condizione che abbia una sessione attiva su service1.

Si noti che il token di sessione stesso non viene mai inviato in un corpo di risposta (quello che vede il client). Potresti semplificare questo schema se lo facessi, quindi lo script client imposterà l'ID di sessione in un cookie per service2, eliminando un round-service2 round-round e un servizio round2-service1 - ma poi un utente malintenzionato con un XSS potrebbe rubare il token di sessione ( al contrario di "semplicemente" che ha il controllo remoto completo sulla sessione compromessa finché l'utente ha caricato la pagina).