Un fornitore di identità può impersonarmi? (Può Facebook pubblicare domande Stack Overflow sotto il mio nome?)

Sì, possono.

Risposta semplice: ti autentichi in qualche modo verso il tuo provider di identità, solitamente tramite nome utente e password. L'amministratore non autorizzato può archiviare le credenziali trasmesse e riutilizzarle. Questo attacco non dipende da come viene implementato il back-end.

In generale, la tua password per il provider di identità non viene utilizzata per l'autenticazione dei servizi di terzi, il che significa che il tuo provider di identità ha effettivamente i tuoi codici di accesso (e non li hai affatto).

Potresti pensare a schemi che incorporano la tua password nel processo di autenticazione senza archiviarla in modo non criptato in seguito, ma in pratica non conosco nessuno di questi schemi.

TL; DR : Un cattivo amministratore di Facebook che può falsificare il tuo login di Facebook può pubblicare cose cattive sotto il tuo nome su Facebook, e che di solito è considerato peggio che pubblicare una domanda su Stack Exchange.

La mia risposta più dettagliata è incentrata su OAuth 2.0 che è lo standard del settore per questo caso d'uso e è dietro lo schema di autorizzazione di Google nell'OP ¹ .

Il framework OAuth 2.0 non è originariamente inteso solo per l'autenticazione, ma per il più generale caso d'uso di autorizzazione: il servizio A vuole accedere ad alcune risorse di proprietà dell'Utente in Servizio B.

Ad esempio, l'Utente ha sia un account sul Servizio A (un'app di modifica delle foto) che sul Servizio B (Google Drive). Con OAuth 2.0, l'Utente concede all'app l'autorizzazione per accedere alle proprie foto su Goole Drive. Alcuni punti di attenzione:

• Il servizio A deve essere un'app registrata sul servizio B: nell'esempio, lo sviluppatore deve registrare la sua app di fotoritocco su Google Developer . Quando si avvia il flusso di autorizzazione, il servizio A si identifica con il servizio B tramite ID client e segreto client (se flusso lato server) o ID client e nome host (se flusso lato client).
• Servizio A reindirizza l'utente sull'endpoint di autorizzazione del servizio B e l'utente deve immettere le credenziali del proprio servizio solo sul servizio B. Il servizio A non può falsificare l'accesso per il servizio B, perché non controlla l'endpoint di autorizzazione. Il servizio B non può falsificare il login per il servizio A, perché non è fornito dall'utente.
• La risposta token finale, che il servizio A può utilizzare per accedere alla risorsa dell'utente sul servizio B, viene fornita con un ambito. Il servizio B consentirà al servizio A di accedere solo alle risorse che rientrano nell'ambito autorizzato. L'ambito è spiegato all'utente nella finestra di autorizzazione a cui sono reindirizzati. Nell'esempio, la finestra di autorizzazione di Google Drive spiegherà qualcosa come "Questa app di modifica delle foto può vedere e modificare le tue foto su Drive" . Google consentirà quindi all'app di accedere alle foto, ma non di pubblicare qualcosa su Google Plus, perché non rientra nell'ambito consentito.

Accesso di terze parti è un caso speciale molto comune, in cui le risorse di proprietà dell'utente sono le informazioni di base sul servizio B. Invece di richiedere all'utente di registrarsi al suo servizio, lo sviluppatore ha scelto per chiedere a Google di verificare l'identità dell'utente.

Il sistema funziona solo se

1. Servizio A trust Servizio B
2. L'utente considera attendibile il servizio B

La cosa bella è che l'utente non deve fidarsi del servizio A.

Se l'Utente, tuttavia, si fida del Servizio A più del Servizio B, non dovrebbe utilizzare l'accesso di terze parti e registrarsi sul Servizio A (quando l'opzione è disponibile).

^{1 Post originale}

Sì, possono. Mario ha spiegato come funziona tecnicamente. Mi concentrerò qui sulla parte trust .

Qualsiasi azione tu faccia su un computer implica fiducia. Ti fidi dell'amministratore del sistema operativo del tuo sistema e del tuo telefono. Ti fidi di tutti gli editor di tutti i programmi che hai installato su di loro. Ti fidi di qualsiasi servizio online che utilizzi. E ti fidi della tua banca di non fare nulla sul tuo account (questo va oltre l'informatica ...).

Ma ci sono alcuni gradi sul livello di fiducia. Mi fido del sistema di prenotazione dei voli abbastanza per comprarli qualcosa, ma non mi fido di loro al punto di dare le mie credenziali bancarie. Ad ogni modo, mi fido del mio programma di protezione password sufficiente per questo.

Quindi, in una catena di fiducia, ciò che conta è: uno degli attori della catena merita solo un livello di fiducia inferiore rispetto all'azione complessiva? Probabilmente è bene usare un account Facebook per SO, il rischio di attacco e le possibili conseguenze sono compatibili con IMHO con la fiducia che ho su Facebook. Ma non utilizzerei mai un account Facebook per la mia banca (non lo offrono comunque). E ovviamente fidarsi di un sistema implica fiducia per i suoi amministratori.

Sì. Questo è il motivo per cui è disponibile una tecnologia che lo rende impossibile (come le credenziali basate sull'attribuzione della privacy), ma è considerato troppo poco pratico per gli utenti medi a partire da ora (e non sono a conoscenza di alcun software con un'usabilità ragionevole e non c'è zero supporto del browser per questo). Questa tecnologia non consente loro di impersonare te e ancor di più così gli accessi possono essere fatti senza connessione a un provider centrale. (Il problema con gli approcci attuali è che perdi i siti che stai utilizzando per il provider di identità).