Facebook oAuth2 per l'applicazione client Javascript

4

Quando si implementa il login di Facebook usando oAuth2 (la versione Javascript), ricevo un token di accesso dal server di autenticazione di Facebook. Fin qui tutto bene.

Il problema che ho è che voglio implementare un back-end RESTful, in cui l'utente deve autenticarsi su ogni richiesta di accesso a una risorsa back-end, utilizzando un token generato dal server. Quello che succede è che quando si utilizza l'accesso standard sul mio sito Web (email + password), questo token viene generato sul server dalla mia applicazione e viene quindi inviato al front-end in cui è memorizzato (tutte le transazioni avvengono su https).

Quindi ho pensato di utilizzare il token di accesso che ricevo da Facebook per memorizzarlo nel mio back-end, se l'utente vuole accedere utilizzando Facebook. In questo modo, ogni richiesta RESTful al back-end potrebbe essere controllata con questo token.

Il problema, tuttavia, è che il back-end non può controllare se il token ricevuto dal client è un token di accesso di Facebook valido (questa è un'applicazione client Javascript, strongmente basata su Ajax per tutte le comunicazioni del server). Anche se posso scrivere Javascript solo per inviare il token di accesso al back-end su autenticazione riuscita con il server FB, questo processo non è affidabile in quanto Javascript non è protetto.

La mia domanda è:

How can I safely store a token in my back end, after the user authenticated with Facebook?

Si noti che sto creando un'applicazione Javascript usando Backbone.

    
posta Trace 16.06.2014 - 14:41
fonte

1 risposta

3

Modifica: ho modificato il flusso di lavoro per il login. Se un utente ha più account di terze parti e ogni account utilizza un indirizzo email diverso, l'indirizzo email non è un identificatore valido. Ora sto usando userId locale.

1) Quando l'utente vuole accedere utilizzando un accesso di terze parti come Facebook o Google, il client richiede un token di accesso con Javascript al server di autenticazione di questa parte. Quando il proprietario della risorsa (utente) viene autenticato, l'ID utente (e altri dati correlati) viene restituito nella risposta, insieme al token di accesso. Questo token è memorizzato sul client sotto forma di cookie persistente a tempo limitato (ad esempio 60 minuti);

2) Il client invia una richiesta Ajax al server Zwoop, inviando la terza parte (FB / Google), l'ID utente di terze parti e il token di accesso con una richiesta POST;

3) Il server Zwoop riceve la richiesta Ajax e invia una richiesta (con PHP) al server di autenticazione di terze parti (in base a quello definito nella richiesta Ajax) per ottenere l'ID utente di terze parti, in base all'accesso token (che è stato ricevuto dalla richiesta Ajax). Quando la corrispondenza di userId ha esito positivo, il server Zwoop ha verificato che il client ha inviato le credenziali corrette.

Questo approccio fa sì che il token di accesso oauth2 funzioni come una password e sia verificato nel back-end contro il server di autenticazione della terza parte. Nessun utente malintenzionato dovrebbe essere in grado di simulare la stessa combinazione di credenziali e la comunicazione avviene su SSL (nessuna intercettazione);

4) Dopo che userId - la verifica della corrispondenza del token è stata effettuata sul server, l'ID utente locale può essere recuperato e restituito al client. L'ID utente locale è l'ID utente definito da Zwoop. Per tutte le ulteriori richieste di risorse per il back end di Zwoop, usiamo userId locale piuttosto che userId di terze parti, questo è il motivo per cui lo recuperiamo in questo passaggio.

Il token può ora essere salvato in MySQL e il token userId + di Zwoop può essere memorizzato nella cache in Redis / memcached.

5) L'ID utente locale Zwoop viene inviato nuovamente al client. Usiamo l'ID utente locale per ulteriori richieste al back-end. Usiamo l'utente di terze parti solo nel caso in cui abbiamo bisogno di accedere a specifiche risorse di terze parti (ad esempio, newsfeed di Facebook, calendario, ecc.). Se l'autenticazione fallisce, l'ID utente non verrà inviato;

Ora è possibile effettuare ulteriori richieste RESTful, mentre il token di accesso oAuth (client) è abbinato al token memorizzato nella cache (server), per identificare se l'utente ha il permesso di accedere a determinate risorse nella nostra applicazione; Quando il cookie o il token di accesso è scaduto, il client ne richiederà uno nuovo e la stessa procedura si ripete.

    
risposta data 16.06.2014 - 17:40
fonte

Leggi altre domande sui tag