'Portare la propria identità' come unica opzione di autenticazione è una pratica valida?

Invece di concentrarsi sull'implementazione di OIDC, voglio affrontare la questione più generale di:

Is BYOID as the only way to authenticate, and thus completely outsourcing authentication, a valid security practice?

Le chiavi pubbliche sono una forma di autenticazione in outsourcing. Ci fidiamo della verifica da parte di terzi della validità di un certificato e di conseguenza l'accesso alle risorse. In questa luce, non sembra irragionevole. Legando la convalida esterna a quella che potrebbe essere la "verifica del crowdsourcing" (cioè i social network), puoi avere un certo livello di conferma che la persona è la persona che ti aspetti che sia.

È vero che l'implementazione ha alcuni ostacoli significativi, ma il concetto è ben accettato in altre forme.

Sì questo è un approccio ragionevole.

Non è un approccio a rischio zero. Se un utente non ha già un account OpenID Connect, o non capisce il concetto, il processo di iscrizione diventa più difficile e rischi di perdere quell'utente. Poiché stai facendo qualcosa di non standard, otterrai alcuni utenti smart alec che infastidiscono i tuoi ragazzi di supporto con lamentele pedanti. E se c'è qualche compromesso futuro, forse un difetto nel protocollo OpenID Connect, potresti sembrare sciocco rispetto ai siti che non hanno mai seguito questo approccio.

Ma a conti fatti credo che sia una buona cosa da fare. La maggior parte degli utenti avrà già un account con una delle principali offerte e sarà felice di utilizzarla, così come utilizzo volentieri il mio account Google per accedere allo stack exchange. Un numero minore di utenti avrà un account con un fornitore minore, che ha scelto perché gli piace la sua politica sulla privacy. E alcuni addirittura eseguiranno il proprio server OpenID Connect. Credo che questo copra le esigenze di tutti, quindi non è necessario fornire un ripiego all'autenticazione di nome utente + password.

Modifica - rileggendo il mio post mi rendo conto di aver fatto due ipotesi:

• Che OpenID Connect diventa uno standard ampiamente utilizzato e di fatto. In caso contrario, è necessario fornire alternative.
• Che il tuo sito non è molto sensibile. Se è così, probabilmente dovresti usare l'autenticazione a più fattori.

No , non credo che lo sia, anche se mi sto concentrando su obiettivi di usabilità più che su obiettivi di sicurezza che forse non è quello a cui ti stai riferendo con questa domanda a causa del punto in cui l'hai postato , ma è importante considerare.

Ci sono persone, come me, che non usano alcun servizio di autenticazione di terze parti. Avere queste come le uniche opzioni di accesso sarebbe negarmi completamente l'accesso al tuo sito web, che altrimenti avrei potuto interessare. Come è vero, solo i grandi siti di social networking come Facebook e forse Google hanno abbastanza trazione da poter essere ragionevolmente sicuro che i visitatori più interessati avrebbero un account con loro. Ma dovresti sempre fornire un'opzione di fallback per coloro che sono interessati ma non hanno / non desiderano utilizzare alcun servizio di terze parti, altrimenti stai negando inutilmente ai partecipanti interessati.

Dipenderà in gran parte dal tuo caso d'uso. Ad esempio, penso che sia accettabile per siti Web come Plug DJ o Stackexchange implementare OpenID. Spesso non offrono altre forme di autenticazione, ma trovo che sia accettabile. Ci sarà un numero di utenti a cui non piacerà perché è di nuovo un altro modo per i social media di raccogliere ancora più statistiche, ma non è davvero un problema di sicurezza.

Dal punto di vista di un'applicazione sensibile, al momento non è fattibile o accettabile per diversi motivi. Percezione della percezione e in secondo luogo il requisito per l'autenticazione a due fattori (che non sono sicuro sia attualmente disponibile).

Anche i controlli di sicurezza dell'applicazione per le password (ad esempio le norme sulle password) sono completamente dipendenti dall'implementazione del provider OpenID. Se i provider OpenID commettono un errore e vengono passate le password, chi sarà ritenuto responsabile in caso di frode sulla tua applicazione?