TL; DR: Non stai usando una passphrase più volte con OpenID, ma altre parti (come Stack Exchange) si fidano del tuo provider di identità (come Google) per autenticarti con attenzione. La passphrase (o qualsiasi altro schema di autenticazione come autenticazione a due fattori, certificati e così via) viene rivelata al provider di identità.
Certificazioni di identità nel mondo reale
Metodi simili sono spesso usati per aprire conti bancari, iscriversi per contratti telefonici o altre azioni che richiedono la verifica della tua identità. Se non vuoi andare di persona a quella società, spesso puoi verificare la tua identità tramite un notaio, un ufficio postale o un'agenzia bancaria, che verificherà il tuo passaporto (è come presentare la passphrase a Google), e poi mano tu (o passa immediatamente a terze parti che richiedono l'autenticazione) un certificato che conferma che hanno controllato la tua identità, ma senza allegare una copia del tuo passaporto.
OpenID
L'idea di OpenID (e di tecnologie simili a single sign on) è che non si immette una passphrase nel sito di destinazione. Ad esempio, se desideri accedere al tuo account Stack Exchange utilizzando Google, Stack Exchange non ottiene mai la passphrase, ma ti reindirizza a Google, che ti autentica (probabilmente hai già effettuato l'accesso a Google, quindi potrebbe semplicemente essere chiesto se si desidera essere autenticati per Stack Exchange e essere rimandati lì).
Stack Exchange non acquisisce la passphrase in qualsiasi momento, non si renderebbe nemmeno conto della modifica della passphrase di Google. Invece, Google assegna un tipo di certificato a Stack Exchange, consegnando alcune informazioni sull'identità, che potrebbero essere solo un identificatore numerico, ma potrebbe anche essere arricchito con informazioni aggiuntive come il tuo indirizzo e-mail.
C'è una bella immagine che descrive il flusso di lavoro su Wikipedia:
" OpenIDvs. Pseudo-AuthenticationusingOAuth "di Saqibali - Opera propria. Autorizzato sotto CC0 tramite Commons .
OAuth
OAuth fa qualcosa di leggermente diverso non passando i certificati, ma una specie di chiave di accesso. Per simulare il comportamento di OpenID tramite OAuth, il provider di identità fornirebbe un servizio semplice che può essere utilizzato solo per l'autenticazione. Se la chiave "si adatta", l'utente è stato autenticato con successo.
Sicurezza
L'intero scenario è sicuro, date alcune precauzioni di sicurezza.
- Non dovresti assegnare la passphrase a un provider di autenticazione falso simile a quello reale (ad esempio, una pagina Google falsa per attacchi phishing). Questo è come fornire il passaporto ad un notaio falso, che farà una copia e farà cose cattive con esso. Questo può essere mitigato attraverso un'accurata verifica dell'URI del sito (i gestori delle password e la ricerca della passphrase automatica per URI sono molto utili con questo!) E utilizzando misure di sicurezza aggiuntive come l'autenticazione a due fattori.
-
Il certificato può essere utilizzato solo per un determinato periodo di tempo ed è valido solo per sito . Ad esempio, un falso sito Web Stack Exchange potrebbe ottenere un certificato. Tuttavia, poiché questo è valido solo per il "falso scambio di casse", l'utente malintenzionato non sarà in grado di usarlo per autenticare contro lo scambio di casse reale o altri siti web.
L'effettiva implementazione di questo differisce tra tutte le tecnologie single sign on, ma tutte implementano un metodo simile per legare i certificati a terze parti.
