Autenticazione dell'utente nello stesso sottodominio utilizzando i cookie

Potresti generare un token di sessione che è puramente lato client utilizzando Token Web JSON .

Il secret può essere condiviso tra i tuoi sottodomini che si autenticano e la tua app. Il segreto viene utilizzato per generare un HMAC sulle attestazioni nel token - nota che non è necessario crittografarlo a meno che non si desideri nascondere i dati dall'utente stesso - l'HMAC impedisce la manomissione dei parametri perché l'utente finale non conosce il segreto per rigenerare l'HMAC.

Nota che condividere i cookie su sottodomini diversi può essere insicuro a meno che non ti fidi completamente di ogni sito in esecuzione in un sottodominio. Questo perché la Stessa politica di origine per i cookie è lassista e non considera un sottodominio o un protocollo diverso come origine diversa . Questo stesso "difetto" è ciò che ti permette di condividere l'autenticazione, tuttavia questo potrebbe non essere giusto per te se non controlli tutti i siti o hai la stessa sicurezza applicata a ciascun sito (un punto debole in uno può minare la sicurezza di tutti ). Gli exploit possibili includono la fissazione della sessione e il dirottamento di sessione in caso di vulnerabilità in qualsiasi sito del dominio principale (anche XSS o CSRF).

Se questo è un problema, usa OpenID o OAuth invece di questo metodo.

È inoltre buona norma impostare il flag di sicurezza sui cookie di autenticazione e utilizzare HSTS per proteggere i cookie da meccanismi di trasporto non sicuri (ad esempio, HTTP semplice).

Tieni presente che le JWT presentano i seguenti punti deboli:

• Non possono essere revocati dal lato server perché esistono esclusivamente lato client.
• Tutto ciò che una funzione di logout può fare è eliminare il cookie, non può impedire a un utente malintenzionato che ha catturato un cookie di continuare a utilizzarlo per dirottare una sessione.
• Qualsiasi modifica della password non interromperà le sessioni esistenti per quell'utente, aumentando l'esposizione in caso di violazione della password.

Esiste un vecchio assioma nel ramo Sicurezza "Non eseguire il rollover ", poiché è spesso molto più facile introdurre aperture di sicurezza piuttosto che chiuderle.

Userei sempre uno standard Internet come Oauth 2 per questo tipo di configurazioni (condividi gli utenti su più siti Web) specialmente quando non l'interazione è desiderata

Riguardo alla sicurezza della tua proposta attuale. nessuna idea. Ho quasi tutte le informazioni per prendere una decisione informata sulla sicurezza di questo sistema. ed è improbabile che possiamo fare qualcos'altro, ma dare alcune indicazioni su cui prestare attenzione.

La chiave qui è stesso sottodominio di dom1.com . Quando questo è vero di solito hai anche la possibilità di condividere lo stesso DB di autenticazione , e in tal caso, accedendo a un qualsiasi posto, verrà scritto un cookie che può essere utilizzato in tutti i posti. Il trucco è assicurarti di impostare il dominio dei cookie come:

dom1.com
(or .dom1.com for very old browsers)

Ora il cookie di autenticazione verrà automaticamente inviato quando si visita uno qualsiasi dei siti. Non è necessario condividere le sessioni affinché funzioni, solo il DB di autenticazione. Ogni sito può ancora avere il proprio DB separato che gestisce la logica specifica di quel sito.