Cross Domain Login – Come accedere automaticamente a un utente quando trasferito da un dominio a un altro

Offriamo una serie di servizi online. Siamo tenuti a sviluppare un sistema che offra agli utenti un’esperienza rapida / semplice se vengono trasferiti da un servizio (su domain1.com ) a un altro servizio (su domain2.com ).

Esiste un modo sicuro per accedere automaticamente a un utente automaticamente una volta che è stato trasferito al nuovo servizio?

Urla contro di me se la soluzione qui sotto è completamente insicura / sbagliata.

Stavamo considerando un sistema simile a quello fornito da una serie di servizi online per il recupero della password: vengono inviati via e-mail un collegamento con un hash unico che scade, che consente loro di cambiare la loro password.

Il domain1.com genererebbe un hash univoco e lo memorizzerebbe in un database con l’hash collegato a un utente insieme a un campo di data / ora in scadenza.

L’utente verrà trasferito su domain2.com/auto/?hash=d41d8cd98f00b204e9800998ecf8427e

domain2.com domain1.com successivamente una richiesta a domain1.com con l’hash per ottenere le informazioni sull’utente. domain1.com rimuoverà quindi l’hash dal database. domain2.com registra l’utente e imposta cookie, ecc.

Potrebbe qualcosa basato su OpenID o OAuth ottenere gli stessi risultati?

    Il Single Sign-On (SSO) è concettualmente piuttosto semplice.

    • L’utente colpisce domain1.com .
    • domain1.com vede che non ci sono cookie di sessione.
    • domain1.com reindirizza a sso.com
    • sso.com presenta la pagina di accesso e sso.com credenziali
    • sso.com imposta cookie di sessione per l’utente
    • sso.com quindi reindirizza a domain1 in un URL speciale (come domain1.com/ssologin )
    • l’URL ssologin contiene un parametro che è fondamentalmente “firmato” da sso.com . Potrebbe essere semplice come una base64 di crittografia dell’account di accesso utilizzando una chiave segreta condivisa.
    • domain1.com accetta il token crittografato, lo decrittografa, utilizza il nuovo ID di accesso per accedere all’utente.
    • domain1 imposta il cookie di sessione per l’utente.

    Ora, il prossimo caso.

    • L’utente colpisce domain2.com , che segue domain1 e reindirizza a sso.com
    • sso.com ha già un cookie per l’utente, quindi non presenta la pagina di accesso
    • sso.com reindirizza nuovamente a domain2.com con le informazioni crittografate
    • domain2.com accede all’utente.

    Questo è il fondamento di come funziona. Puoi renderlo più robusto, più ricco di funzionalità (ad esempio, questo è SSOn , ma non SSOff , l’utente può “disconnettersi” da domain1 , ma deve comunque accedere a domain2 ). È ansible utilizzare le chiavi pubbliche per firmare le credenziali, è ansible avere richieste di trasferimento di ulteriori informazioni (come i diritti di authorization, ecc.) Dal server SSO. È ansible avere un’integrazione più intima, ad esempio i domini che verificano regolarmente che l’utente abbia ancora i diritti dal server SSO.

    Ma l’ handshake dei cookie tramite il browser che utilizza i reindirizzamenti è il fondamento chiave su cui si basano tutte queste soluzioni SSO.

    Sarebbero in grado di rubare il trasferimento del dominio incrociato se qualcuno fosse in grado di giocare l’uomo nel mezzo e afferrare quell’hash? Ovviamente ha bisogno di essere generato e inviato al cliente prima di aver bisogno di usarlo. Ad esempio, ad esempio:

    Sto interpretando l’uomo nel mezzo spiando Jack. Jack accede a domain1.com che fa sì che un hash venga preparato e inviato a lui in modo che quando accede a domain2.com possa inviare quell’hash come autenticazione. Mentre accede a domain1.com , la sua richiesta viene da me, tu restituisci la pagina, prendo l’hash e lo lascio continuare. Ho accesso a domain2.com usando l’hash, ora mi hai lasciato in domain2.com e ho cancellato l’hash. Non ne sa nulla fino a quando non tenta di accedere a domain2.com e viene detto che le sue credenziali non sono più valide.

    Come lo superi?

    Non ci sarebbe alcun punto usando SSL per il login tra domini a meno che non si usi SSL per l’intera sessione. È altrettanto facile rubare un cookie di sessione quanto utilizzare un hash in un URL. Qual è il punto nel hide l’hash in SSL se il resto della sessione non è sicuro.

    Il metodo indicato in alto è praticamente il metodo standard. Se si sceglie di utilizzare protocolli sicuri è completamente diverso, ma sarebbe inutile criptare solo parte della sessione.

    Questa è una buona soluzione. Ecco due punti da considerare:

    Si usa il termine “hash”, ma non è chiaro quali dati verranno cancellati. Invece, usa un “nonce”: un grande numero (128 bit) generato da un RNG di qualità crittografica.

    Inoltre, non l’hai specificato, ma le comunicazioni tra l’utente e entrambi i domini e tra i domini stessi devono essere sicure. Utilizzare SSL per autenticare i server e mantenere il nonce confidenziale.

    Che dire del SEO? Sembra che ogni richiesta prima che l’accesso succesfull venga reindirizzato ad altri domini e viceversa. Direi che è molto brutto. Quali intestazioni dovresti inviare? 301 a SSO e quindi indietro 301 alla pagina originale? Quindi il “search bot” è “richiesto” per cambiare il suo indice per quella pagina due volte?