Memorizzazione delle informazioni OpenID necessarie

Question

Sto cercando di implementare l'autenticazione OpenID per il mio sito. Ecco lo scenario:
voglio che l'utente sia in grado di

• login utilizzando solo OpenID (. Utente può solo ottenere verificato visitando provider OpenID non c'è bisogno di creare un account personalizzato con la posta elettronica-password),
• Via email/password (l'utente si è registrato sul sito compilando un modulo)
• Allega gli ID aperti ai propri account (openids + email per un account).

Ora non so quali credenziali dovrei memorizzare per l'id aperta. e non sono sicuro dello schema del DB. Ecco lo schema del database:

Table: Users 
UserId => PK 
... => Custom info. Not related to authentication. 

Table: Authentication 
AuthenticationId => PK 
LoginId => (when custom site membership => email address) (when openId => openid unique address) 

UserId => FK to Users. 
Provider =>(when custom site membership => "CUSTOM") (when openId => openid provider address) 
Password => filled when using custom membership. empty when using open id. 

Ora, quando un utente accede a, sia utilizzando l'appartenenza OpenID/custom, mi basta guardare a tavola l'autenticazione e cercare credenziali e ottenere l'utente appropriato. Se nessun utente esiste, creo un nuovo utente e aggiungo una voce nella tabella di autenticazione.

• La domanda principale: memorizza Provider e LoginId (si vedano i commenti qui sopra per vedere ciò che viene memorizzato in questi campi) sufficiente per la memorizzazione di autenticazione OpenID? Devo memorizzare dati aggiuntivi in ​​modo che quando l'utente ritorna, posso autenticarlo in base ai miei dati salvati?

• Suggerite qualche altro (più efficiente) approccio per implementarlo?
  Grazie.

Answer 1

Memorizzare ClaimedIdentifier per l'utente openid, non l'indirizzo del provider. L'Identificatore Rivendicato è ciò che il protocollo OpenID verifica è univoco per l'utente e inoltre fornisce potenzialmente la portabilità tra i provider OpenID.

Inoltre, poiché gli Identificatori Rivenduti di OpenID 2.0 possono essere deprecati da OpenID Connect (un successore incompleto di OpenID 2.0), potrebbe anche essere nel vostro interesse registrare l'URI dell'endpoint del provider OpenID e l'indirizzo e-mail asserito dal Provider nel record dell'utente. Per ora, fare non utilizzare questi come parte del flusso di autenticazione, ma registrandoli, sarà in grado di determinare in seguito gli indirizzi di posta elettronica 'fidati' (supponiamo che tu decida che gli indirizzi e-mail asseriti da Google sono affidabili) e consentire all'utente di migrare in tal modo il proprio account a uno OpenID Connect uno utilizzando tale indirizzo di posta elettronica verificato. Ciò si ridurrà anche contro il pericolo che il reame del tuo sito web (di solito http://yourdomainname.com) cambi e causi la modifica di tutti gli identificatori del tuo account Google, che possono essere recuperati in modo tragico solo tramite il loro indirizzo email.

Si consiglia inoltre di utilizzare tabelle diverse per i diversi tipi di autenticazione. Ci sono un paio di vantaggi qui. Il più importante è che, dal punto di vista dell'architettura, è più difficile introdurre un buco di sicurezza nel tuo sito web che potrebbe consentire a qualcuno di entrare (per esempio) un OpenID nel campo del nome utente e una password vuota e farlo apparire come partita e accesso al database senza che si verifichino autenticazioni reali. In secondo luogo, fornisce un modello più flessibile nel caso in cui si desideri aggiungere un terzo meccanismo di autenticazione anziché fare in modo che la tabella "Autenticazione" cresca orizzontalmente per tutti gli utenti. Ad esempio, OAuth 2.0 e "OpenID Connect" introdurranno probabilmente nuovi tipi di autenticazione al tuo sito quando ne aggiungerai il supporto nel corso degli anni e l'aggiunta di nuove tabelle per gestire i nuovi tipi di dati sembra adattarsi meglio.

Answer 2

Abbiamo appena archiviato l'URL di richiesta openid. Si consiglia di richiedere ulteriori informazioni dal provider come il nome dell'utente. La cosa più importante è separare appartenenza e autenticazione.

Il nostro schema è stato

Profiles 
-------- 
UserId 
FirstName 
LastName 
etc. 

Users 
----- 
Username 
Password 

Profiles.UserId è semplicemente una proprietà di stringa che memorizza sia il nome utente interna utenti o loro URL OpenID pretesa, a seconda di come si sono registrati.

In caso di autenticazione avvenuta con successo (utilizzando un nome utente interno/password o un provider esterno), basta impostare il proprio cookie di autenticazione utilizzando il proprio nome utente interno o l'URL del reclamo. Ottenere il profilo dell'utente è quindi solo questione di trovare il profiler dove (UserId == User.Identity.Name).

Questo ha il vantaggio che un utente può scegliere di cambiare il modo in cui si autenticano in qualsiasi momento (magari passando a un account interno o utilizzando un provider diverso).