Come dovrei progettare un webservice RESTful per utilizzare terze parti (ad esempio Google, Facebook, Twitter) per l'autenticazione?

Sembra che ci siano due obiettivi:

1. Facile da autenticare per gli utenti finali con i loro account social esistenti
2. Facile per gli sviluppatori che usano il tuo webservice

Autorizzare le persone a utilizzare le risorse sul tuo sito rende OAuth2 un meccanismo preferito a causa della popolarità e della disponibilità delle librerie client.

1. Facile da autenticare per gli utenti finali con i loro account social esistenti

L'utente finale visita un sito che utilizza la tua API e sceglie di accedere. Vengono inviati alla tua pagina di accesso OAuth. La tua pagina di accesso mostra un normale nome utente e una password per gli account gestiti sul tuo sito e una serie di pulsanti di autenticazione sociale dove possono fare clic per accedere tramite un sito come Facebook. Quando l'utente sceglie Facebook, li reindirizza su Facebook per approvare la scelta (avviando il flusso di autenticazione di Facebook). Quando l'utente finale completa il login su Facebook, viene reindirizzato al tuo sito.

Quando l'utente viene reindirizzato al tuo sito da Facebook, salva le informazioni dell'utente in un record utente nel tuo database e quindi genera una nuova sessione per quell'utente. Immediatamente reindirizza l'utente finale al loro sito originale downstream con oauth access_token, completando il flusso oauth originale.

2. Facile per gli sviluppatori che utilizzano il tuo webservice

Se sei il fornitore di autorizzazione, dovresti creare una semplice interfaccia per gli sviluppatori che dipenda da ciò che non cambia ogni volta che aggiungi un nuovo provider di autenticazione upstream che non implementa perfettamente oauth. Questo è il motivo per cui credo che dovresti implementare un sito di provider OAuth2 e tale sito dovrebbe essere un consumatore dei siti di autenticazione sociale.

Per lo sviluppatore che utilizza la tua bella API di riposo, non saranno a conoscenza dell'interazione di Facebook a meno che tu non scelga di dare loro un suggerimento attraverso il post di acquisizione della sessione (per esempio).

TL; DR

Rendi gli utenti delle tue API come te implementando OAuth2 e nascondendo le complessità dell'autenticazione sociale. È possibile, durante il flusso di oauth per i siti a valle, attivare un flusso aggiuntivo oauth con Facebook.

Immagine perché immagine == parole * 1000:

Possiamo chiamare questo oauth2-piggy-back?

Flusso graduale

1. Sito visita utenti finali che utilizza la tua API
2. L'utente finale viene inviato al tuo sito per autorizzare o iscriversi (oauth2)
3. L'utente finale seleziona l'autenticazione social, fa clic sul pulsante di accesso di Facebook
4. Il tuo sito imposta un cookie o imposta state su facebook oauth per sapere da dove proviene l'utente
5. Utente finale reindirizzato su Facebook e accetta la connessione sul sito di facebook
6. Utente finale reindirizzato al tuo sito per completare il processo di autorizzazione di Facebook
7. Stai cercando o crea l'utente nel tuo database
8. Crei una nuova sessione sul tuo server
9. Reindirizza l'utente al suo sito originale con il token di sessione

Come renderlo estensibile

Per prima cosa dovresti notare che tutte queste API utilizzano lo stesso meccanismo per l'accesso. Tutti usano OAuth per la loro autenticazione. Questo è necessario sfruttare iniziando con una libreria OAuth generale. Non utilizzare le proprie librerie per l'autenticazione, queste saranno inutilizzabili per altri provider. Se si ottiene il blocco di OAuth2 è abbastanza semplice aggiungere più provider.

Ne hai bisogno, sfortunatamente, due, perché Twitter non ha ancora superato il carrozzone OAuth2.

OAuth ha bisogno di te per creare un'interfaccia per la parte che autentica. I token verranno scambiati da server a server. Crea un punto di accesso, in grado di gestire tutte le comunicazioni.

Il token deve essere memorizzato in una tabella separata dal tuo account, questo perché possono essere più token e più profili collegati. Alcuni servizi ti danno due token, uno di questi è un token di aggiornamento.

Ora hai progettato un'interfaccia, che racchiude l'altra funzionalità di cui hai bisogno. Personalmente avrei creato un servizio REST separato per questo. In questo modo puoi facilmente estendere l'autenticazione ad altri posti.
Alcuni servizi usano JSON per comunicare, altri per XML ecc. Per l'utente anteriore è necessario unificarli tutti. Questo è un processo piuttosto doloroso, ma qui è possibile ricavarne alcuni motivi comuni.

Un altro problema qui è che non tutti i servizi forniscono la stessa funzionalità. Ciò può significare che i tuoi servizi non possono fornire l'API completa come specificato. È necessario disporre di una strategia qui, che consente all'applicazione di eseguire il downgrade con garbo.

Tutto ciò ti garantirà la possibilità di aggiungere facilmente nuovi fornitori di terze parti.

Problemi con i token

I token sono limitati nel tempo, quindi hai bisogno di un paio di job cron, che possono controllare se il token è ancora utilizzabile, altrimenti devi cancellarlo. Puoi anche aggiornare un token con questo meccanismo.

Talvolta accade che un utente ritiri il token. Sii pronto per questo.

Archiviazione dati

Se hai questo design, devi pensare ai dati che ti servono. Questo deriva in parte dalla tua interfaccia appena creata. Disegna alcune tabelle per questo e guarda se i dati sono effettivamente recuperabili. Alcuni servizi non ti consentono di acquisire molti dati. Dovresti anche tener conto del fatto che più dati hai bisogno, più alto diventa il messaggio sulla privacy. Quindi sii modesto nei tuoi bisogni, altrimenti gli utenti non lo useranno.

Per ulteriori verifiche, è possibile memorizzare i profili in una tabella separata ma collegata agli utenti. Questo ti fornirà molte più informazioni su qualcuno.

Controlla anche le leggi locali, per alcuni dati hai bisogno di precauzioni extra.

Ultima cosa Non commettere l'errore se non si crea un account sui propri servizi. Se l'utente viene bannato da Facebook, sarà effettivamente in grado di accedere al servizio. Questa è una situazione che non vuoi creare. Questo è spesso trascurato.

Sicuramente sceglierei la soluzione che sembra aver già capito: implementare l'autenticazione di terze parti sul tuo sito Web client e quindi associare quei token di autenticazione di terze parti con gli account utente del tuo sito web e infine attivare il tuo chiamata setSessionID all'accesso.

A seconda dell'architettura del tuo sito web, potresti trovare una libreria come EveryAuth o Passaporto per essere molto utile.

I miei due centesimi: non ho mai fatto nulla di simile prima né so come funzionano i meccanismi di login di FB, Twitter o Google, ma alcuni problemi mi sono venuti in mente non appena ho letto la tua domanda:

• Login multipli: Cosa succede se effettuo l'accesso con il mio account Facebook un giorno e il mio account Google il prossimo? O contemporaneamente? Tratti questi due account come account unici e separati o dovresti avere qualche metodo per associare i due e permettermi di accedere ai miei ticket in entrambi i casi?
• Affidarsi a identificatori esterni: cosa succede quando Facebook o Twitter decidono di cambiare il modo in cui appaiono gli identificatori di account? Per illustrare, se BazLogin rappresenta un account univoco utilizzando il codice {4382-af56} ma si decide che d'ora in poi gli account avranno 12 cifre perché 8 non erano sufficienti, come si dice a {1234-4382-af56} da {FREQUENZA4382 -af56}?

Possiamo gestire questi due problemi scegliendo di associare gli account esterni con un account interno, non solo un ID di sessione. Quindi, un accesso esterno potrebbe essere solo un gateway per la creazione di un account interno. Se dovessi eseguire l'autenticazione con più di un metodo di accesso, potresti dirmi che ho già effettuato l'accesso. Se un fornitore di autenticazione esterna modifica qualcosa su cui fare affidamento, potremmo chiedere all'utente di fornire il nome e la password del proprio account interno e creare un nuova associazione per accessi futuri.

Non sono sicuro di aver affrontato i problemi che avevi in mente, ma non hai menzionato alcun problema concreto. Spero che la mia risposta sia stata utile, in entrambi i casi.