Accesso social + API REST protetta da OAuth2

Question

Accesso social + API REST protetta da OAuth2

#1 da (1 voti)

11

Sto implementando l'accesso social con Facebook, Twitter e Google+ sulla nostra API REST protetta da OAuth2 (protetta usando spring-security-oauth ). Mi piacerebbe assicurarmi che il flusso seguente sia sicuro e che non stia introducendo buchi di sicurezza.

Panoramica

Esiste un'API REST e tre tipi di applicazioni client: web, iOS e Android. La comunicazione tra l'API e le applicazioni client avviene tramite HTTPS.

Flusso

Le applicazioni client avviano il flusso di accesso social tramite il browser o le app native e realizzano l'intera "OAuth dance". Ottengono un ID utente e un token di accesso corrispondenti a questo ID utente.
Le applicazioni client inviano l'ID utente e il token di accesso all'API REST come parametri POST al nostro endpoint token OAuth2 che specifica un grant_type personalizzato ( facebook , twitter o google ).
L'API REST contatta il social network corrispondente e lo convalida
- Il token di accesso è attivo.
- Il token di accesso è stato generato per l'utente specificato e per la nostra applicazione.
Se le condizioni di cui sopra sono soddisfatte, prendiamo dal nostro DB l'utente con l'ID esterno specificato e generiamo il nostro token di accesso che può essere utilizzato in ulteriori richieste. Il token di accesso è mai salvato nel nostro database, solo l'ID utente.

Mi piacerebbe sapere se questo è il modo corretto di implementare l'accesso social in questo scenario e se ci sono delle insidie a questo intero flusso.

rest authentication oauth

posta Martin 18.02.2015 - 11:02

fonte

1 risposta

Leggi altre domande sui tag rest authentication oauth

Perché IE11 rifiuta di abilitare la memorizzazione nella cache di back back per HTTPS? I numeri di previdenza sociale sono inutili da soli?

score 1 · Answer 1

Il tuo flusso sembra corretto come dichiarato, ma ci sono difficoltà. Lasciami spiegare.

La prima è la distinzione tra "autenticazione" e "autorizzazione". L'accesso social si concentra sull'autenticazione: piuttosto che accedere con l'utente / la password dell'applicazione (o qualsiasi altra cosa), si consente all'utente di accedere già con Google, Twitter o Facebook.

Una volta che l'utente ha effettuato l'accesso (con qualunque mezzo), la TUA applicazione decide cosa è autorizzato a fare. Possiamo dimenticare che siamo arrivati qui tramite OAuth 2 (accesso social) anziché tramite il normale accesso al sito. Quel flusso sembra buono.

Dov'è il problema di sicurezza? In questo "OAuth 2 dance", che è il tuo passo 1, assicurati di seguire i documenti attuali forniti da Google, Twitter e / o Facebook. NON esporre la chiave API segreta dell'applicazione al lato client (browser o app nativa). In altre parole, parte della danza deve essere eseguita lato server. È molto facile sbagliare, e QUESTO è il trabocchetto.

C'è un altro modo di guardare a questo. La tua applicazione potrebbe scegliere di agire come un client OAuth 2. Il token fornisce non solo l'autenticazione, ma anche l'autorizzazione. Il token indica alla tua applicazione ciò che questo utente è autorizzato e non autorizzato a fare nella tua applicazione. Questo è il classico caso d'uso di OAuth: un'applicazione di terze parti è autorizzata a svolgere alcune attività (come ottenere e stampare foto) senza disporre delle credenziali di accesso dell'utente.

Lavorando con OAuth 2, puoi evitare molte insidie facendo molta attenzione alla distinzione tra autorizzazione e autenticazione. L'OP fa correttamente questa distinzione.