2013-04-22 27 views
17

Ho fatto alcune indagini sull'autenticazione api restful. La maggior parte delle persone ha indicato Oauth2 per l'autenticazione api riposante. Ho esaminato alcune delle risorse, in particolare questo collegamento https://developers.google.com/accounts/docs/OAuth2.confusione di autenticazione api restful con oauth2

Mi sembra che Oauth2 sia un'applicazione di terzi per accedere ai dati degli utenti su google/facebook (o altri fornitori di dati).

Il nostro problema è che noi possediamo i dati, non abbiamo bisogno di accedere ai dati di terze parti dei nostri clienti e i nostri clienti non hanno alcun dato di terze parti. Vogliamo proteggere la nostra API con una sorta di autenticazione.

Per il nostro caso, quali sono le tecnologie convenienti per la nostra autenticazione api restful? Esporremo la nostra API come questo

https://ourdomain.com/api/<endpoint> 

I nostri clienti possono accedere a un sito web prima di registrare https://ourdomain.com e dovrebbero essere in grado di ottenere clientId e clientKey dal nostro sito web per l'accesso API. I nostri clienti dovrebbero essere in grado di consumare tramite una sorta di autenticazione

+0

Come stai esponendo la tua api? è solo per il tuo consumo (ad esempio il tuo sito web/app per dispositivi mobili)? – rhinds

+0

@rhinds Ho aggiornato il mio post. Grazie – wwli

+0

Quando dici che i nostri clienti consumeranno l'API - chi/quali sono i tuoi clienti? – rhinds

risposta

5

Se ho capito bene, cosa ti serve in modo simile a OAuth in modo che tu faccia esattamente la stessa cosa, meno di concedere a un'app di terze parti l'accesso alle risorse di un utente.

In OAuth, esiste un sistema centrale che gestisce l'autenticazione e l'autorizzazione controllando le credenziali di un'app + le credenziali dell'utente e scartando i token di autorizzazione. Esistono più endpoint che accetteranno questi token di autorizzazione.

I token sono in pratica stringhe crittografate che contengono informazioni sulle credenziali dell'utente e alcune altre informazioni che potrebbero essere necessarie all'app.

Quello che ti serve (credo) è un simile endpoint di autenticazione, che il client colpisce con le sue credenziali e ottiene un token.

Quindi,
i) Creare un modulo di registrazione/console in cui un cliente può registrarsi e ottenere le proprie credenziali. Dai un'occhiata a this.
ii) Definire un endpoint HTTP in cui l'utente scambia le proprie credenziali per un token di accesso + token di aggiornamento.
iii) Il client può raggiungere l'endpoint della risorsa con i token di accesso per effettuare chiamate autenticate a qualsiasi endpoint.
iv) Al back-end è necessario un servizio comune che verifica i token e ne estrae le informazioni.

PS - Questo è solo un sistema minimale, ci sarebbero molte considerazioni sulla sicurezza come se alcune app non autorizzate avessero accesso ai token di accesso di alcuni client.
È possibile trovare molte informazioni sugli attacchi CSRF, noonces, timestamp e altri metodi per mitigare i problemi di sicurezza.

10

In oAuth 2.0, esistono diversi tipi di tipi di sovvenzioni. Un tipo di concessione è solo un modo per scambiare qualche tipo di credenziali per un token di accesso. In genere oAuth fa riferimento all'utilizzo di terze parti con una concessione di codice di autorizzazione. Ciò significa reindirizzare l'utente al sito Web del proprietario della risorsa per l'autenticazione, che restituirà un codice di autorizzazione.

Questo chiaramente non ha senso per l'uso di 1a parte oAuth, dal momento che SEI il proprietario della risorsa. oAuth 2.0 ha preso in considerazione questo e ha incluso la concessione delle credenziali per la password del proprietario di risorse a tale scopo. In questo caso, puoi scambiare un nome utente e una password per un token di accesso a livello di prima parte.

Vedere http://tools.ietf.org/html/rfc6749#section-4.3 per ulteriori dettagli.

2

tanto per essere chiari con la domanda iniziale:

OAuth2 ha bisogno di almeno un client e un server

OP si stava chiedendo come proteggere un'API REST, e perché tutti parlano di terze parti provider di autenticazione (Google, Facebook, ...)

ci sono 2 diverse esigenze qui:

1 - Essere in grado di garantire un API personale (ourdomain.com)

Client    Server 
Consumers <----> Your API 

2 - Essere in grado di consumare un'API pubblica (ad esempio ricevendo lista dei contatti di Google di un utente)

Client    Server 
You  <----> Google APIs 

OP ha bisogno in realtà il primo: implementare un server OAuth2 di fronte alla propria API.
Ci sono many existing implementations for all languages/frameworks on Github

Infine, ecco one nice Oauth2 technical explanation, e sto spudoratamente prendendo uno dei suoi schemi qui:

Google OAuth2 schema

No non sto lavorando a Google, sto solo prendendo Google come esempio di fornitore di API pubbliche.

+0

Pierre, ho una domanda. Sto pensando di creare un sistema di API 2 server. In sostanza, qual è il vantaggio dell'utente API che recupera un token e lo passa con ogni chiamata API, mentre l'utente API fornisce solo la propria password (o chiave permanente) con ogni chiamata API? – Dave

+0

Con un token, la password non sta transitando dalla rete, quindi non può essere rubata. Il token cambia continuamente, quindi può essere riutilizzato se rubato –

+0

Tuttavia, la password deve essere trasmessa una sola volta per ottenere il token in primo luogo, correggere? C'è ancora almeno un punto di visibilità. Se sto capendo correttamente, ciò sarebbe utile solo se un'organizzazione avesse aumentato le procedure di sicurezza in cui uno sviluppatore distribuiva i token OAuth e tutti gli altri sviluppatori approvavano le richieste in arrivo tramite token, in modo che più programmatori non avessero visibilità diretta della password. (l'entità che gestisce i server OAuth avrebbe bisogno di un'autorizzazione top secret o qualcosa del genere) Quindi è il momento dell'autenticazione a 2 fattori. – Dave

Problemi correlati