OAuth è una buona scelta per l'API RESTful in questo scenario SaaS?

Question

OAuth è sensato da utilizzare quando le informazioni sull'account utente (ID utente, password, ruoli, ecc.) Verranno mantenute nel nostro back-end e quando non ci sarà alcuna condivisione di risorse con altri siti? O sta condividendo l'intero punto di utilizzo di OAuth?

Background:

sto lavorando sullo sviluppo di un prodotto SaaS enterprise e stiamo creando un RESTful API per essere utilizzati da nostre applicazioni front-end. I consumatori dell'API saranno le applicazioni per smartphone e smartphone nativi (iOS & Android) che sviluppiamo. Dal momento che supporteremo più tipi di client, ha senso creare un'API RESTful che tutte le nostre app client possano consumare.

Ovviamente abbiamo bisogno di proteggere questa API RESTful. Stiamo prendendo in considerazione l'autenticazione tramite HTTPS/Basic Auth, ma siamo a conoscenza di alcuni dei ben noti inconvenienti di questo approccio.

Alcune ricerche veloci mostrano che OAuth è altamente raccomandato. Ma la maggior parte di ciò che trovo con OAuth è nel contesto dell'autorizzazione dei siti Web a condividere informazioni per conto dell'utente.

Qualsiasi informazione se più gradita.

Answer 1

Buona domanda, e stiamo avendo una buona discussione su questo oltre alle API Craft:

https://groups.google.com/group/api-craft/browse_thread/thread/b87fd667cccb9c00

Ecco la risposta che ho postato lì:

Credo che questo sia un buon uso caso per OAuth, in realtà.

Prima di tutto, con OAuth la tua app mobile può memorizzare un token OAuth sul client piuttosto che la password "reale" dell'utente.Quindi, puoi fare in modo che l'app "registri l'utente" automaticamente ottenendo un token OAuth senza dover memorizzare la password effettiva sul dispositivo. Se l'utente perde il dispositivo o se è compromesso, in qualche modo (o tu) può cancellare il token OAuth senza richiedere che l'utente cambi la password e spazzare via altre cose che potrebbero fare con la tua API. Esistono esempi simili per un'app Web in stile Ajax ma dipende più dal modo specifico in cui si crea il client.

In secondo luogo, il token OAuth è associato a una chiave univoca che identifica l'app che sta effettuando la chiamata API e che a sua volta identifica quale sviluppatore ha creato l'app. Ciò ti offre opzioni come il monitoraggio dell'utilizzo per applicazione, la disattivazione di un'applicazione che potrebbe essere stata compromessa senza disattivare l'intera API e, se desideri aprire l'accesso a terze parti o partner che creano app per la tua API, puoi offrire diversi livelli di servizio ad altri clienti.

In terzo luogo, le persone che si occupano di sicurezza IT saranno contente se gli dirai che non memorizzi mai una password sul dispositivo mobile dell'utente o la riponi da qualche parte nel browser.

In quarto luogo, l'opzione di accesso basato su browser per l'app mobile è disponibile. Ciò significa che l'app mobile non vedrà mai la password dell'utente e anche che se si desidera implementare la sicurezza a due fattori o qualcosa del genere, è possibile farlo nella schermata di accesso senza modificare le app mobili. Ora, il lato negativo è che l'utente vede apparire una finestra del browser. Ecco perché OAuth ti offre alcuni modi diversi per ottenere un token di accesso per un'app, quindi puoi scegliere se devi avere un accesso basato su browser o se l'utente deve inserire la password direttamente nell'app.

In quinto luogo, come fai a sapere che la tua API verrà sempre utilizzata solo dalle tue app? Se utilizzi OAuth ora, avrai più tempo a effettuare questa transizione in un secondo momento.

Answer 2

OAuth è solo un token e l'App richiedente ne emetterà uno. Puoi leggere di più su pingidentity.com dove ci sono diversi webinar su questo argomento (identità cloud e provisioning utente).

Answer 3

Ho implementato un OAuth per Django nonrel con pistone per esporre le mie API al consumatore. Ci sono un certo numero di tipi in OAuth (2-legs 3legs).

Generalmente, supportare OAuth è una bella sfida. Devi ottenere il token di richiesta, autorizzarlo, memorizzare il token di accesso per firmare ogni richiesta che desideri autenticare.

Vantaggi
- Non c'è bisogno di inviare username e password ogni volta, sicuro.
- Abilita terze parti a consumare la tua app.
Svantaggi
- Effettuare 2,3 viaggi di andata e ritorno per l'autenticazione.
- Complicato per implementarlo da solo.

Sono abbastanza sicuro che è possibile trovare un numero di libreria che consente di:
- Esporre l'API e supportare OAuth. Pistone Django.
- Firma le tue richieste aggiungendo loro delle intestazioni. E.g Oauth-signpost.

Answer 4

Sì, questo è un ottimo adattamento per OAuth. È ancora possibile utilizzare HTTP Basic su SSL durante l'handshake per l'autenticazione. L'output dell'handshake OAuth sarà un token che può quindi essere utilizzato per consumare l'API. In questo modo, l'applicazione non ha bisogno di memorizzare le credenziali e i token possono essere facilmente revocati con un impatto minimo sull'utente.

OAuth 2.0 definisce un numero di tipi di sovvenzioni differenti per l'adattamento di diverse situazioni. Mi sembra che le credenziali "implicite" o "password del proprietario della risorsa" siano le più appropriate, ma puoi prendere in considerazione ognuna attentamente.

Non è necessario implementarlo direttamente nell'API, ma utilizzare l'infrastruttura per delegare il supporto OAuth e la gestione dei token per conto della propria API SaaS.

Date un'occhiata a

http://www.layer7tech.com/blogs/index.php/oauth-token-management-2/

e

http://www.layer7tech.com/products/oauth-toolkit

Spero che questo aiuto,

"contesto di autorizzare .."

-FL