Posso sbarazzarmi della memorizzazione dei segreti degli utenti usando OpenID e cosa devo memorizzare?

Naviga le tue risposte
1

Quali informazioni devi tenere su un utente per essere un consumatore OpenID?

Voglio utilizzare OpenID per consentire agli utenti di registrarsi e autenticarsi sul mio sistema. Quindi, mentre ci sto lavorando, non voglio duplicare gli sforzi ed eliminare le password non necessarie, ecc. Da essere memorizzate.

Suppongo che, oltre ai dettagli del profilo dell'utente, sia necessario memorizzare una copia del token di autenticazione / ID dell'utente dal provider ID nonché l'URI ID utente e un indirizzo email di ripristino nel caso in cui il provider ID diventi inaccessibile o l'utente vuole collegare un nuovo fornitore di ID al proprio account sul proprio sistema. Sembra anche che ci sia un token temporaneo di "richiesta" utilizzato durante l'iscrizione e / o durante la ri-autenticazione, ma questo è di breve durata e usato una sola volta, quindi potrebbe non essere necessario memorizzarlo nel database.

Diversi fornitori di ID, ad esempio Facebook, Twitter, LinkedIn, Google Connect forniscono tutti token di autenticazione abbastanza simili che posso semplicemente chiamare le colonne del database qualcosa come "IDProviderToken" e "IDProviderURI", o ho bisogno di dati specifici per Facebook / Google / etc?

    
posta Johan 21.01.2015 - 13:19
fonte

2 risposte

2

Ciò che conservi per l'utente è la tua decisione. L'implementazione di base è la conservazione di un ID utente (quello ricevuto dal provider ID aperto) e il token che si riceve dal provider dell'ID aperto (che include token di accesso, scadenza e token di aggiornamento). qualunque cosa tu voglia mantenere oltre questo dipende da te.

Per quanto ne so, ogni provider di openid connect deve rispondere con la stessa struttura dati ... fa parte del protocollo, ma openid ha tre versioni: 1.0, 2.0 e connect

Alcuni esempi di fornitori: Google e Microsoft Azure ora utilizzano openid connect per i loro servizi openid. Yahoo utilizza openid 2.0 Hai menzionato Facebook - non sono un fornitore openid, hanno il loro protocollo unico

    
risposta data 21.01.2015 - 16:27
fonte
0

Alla fine ho scelto di non usare nessuna forma di OpenID (e nemmeno nessuno dei suoi amici)

Nel mio progetto, a seconda dei provider openID, è stata introdotta una configurazione di sicurezza non valida. Il principio è che nessun sistema dovrebbe dipendere da un altro sistema per la sicurezza dove l'altro sistema ha una garanzia di livello di sicurezza inferiore o sconosciuta rispetto a quella richiesta dal sistema.

Mentre OpenID in linea di principio è buono, l'implementazione è lasciata ai fornitori e non ci sono sostanzialmente garanzie.

La JWT da sola ha dimostrato di offrire ciò che era necessario: a) Sbarazzarsi della memorizzazione dei segreti degli utenti usando il principio di "Qualcosa che hai" in contrasto con l'uso comune di "Qualcosa che conosci" (sotto forma di password) come mezzo di autenticazione. Ciò ha dimostrato di avere ulteriori vantaggi rendendo il server "stateless" e più performante eliminando le ricerche su tabelle utente di grandi dimensioni. b) Il mantenimento delle sessioni sul lato client elimina ulteriormente le sessioni gestite lato server. c) La possibilità di utilizzare un metodo per aggiornare token utilizzando un attributo che non è memorizzato nel token aumenta la sicurezza (ad esempio, una parte dannosa ha bisogno sia del nome utente AND di un token valido esistente per poter rinnovare qualsiasi token).

Aside / FWIW: Quando ho fatto questa domanda 3 anni fa, sul Web era disponibile pochissimo su questo argomento.

    
risposta data 03.12.2018 - 10:39
fonte

Leggi altre domande sui tag

Come funziona la regola DROP in iptables? Blocca le richieste http HEAD, TRACE, DELETE O TRACK è una funzione di sicurezza valida? [duplicare]