Proteggere la mia API REST con OAuth pur consentendo l'autenticazione tramite provider OAuth di terze parti (utilizzando DotNetOpenAuth)

Ho un prodotto con un'API REST semplice in modo che gli utenti del prodotto possano integrarsi direttamente con le funzionalità del prodotto senza utilizzare la mia interfaccia utente web.

Di recente ho ricevuto interesse da varie terze parti sull'integrazione dei loro client desktop con l'API per consentire agli utenti del mio prodotto di accedere ai propri dati utilizzando tale applicazione di terze parti.

Ho visto che le applicazioni che desiderano utilizzare Twitter eseguono l'autenticazione utilizzando una pagina di accesso ospitata da Twitter che concede un'autorizzazione specifica all'applicazione per accedere ai dati dell'utente. Fai clic sul pulsante "Consenti" o "Nega" e il processo di autenticazione è completo. Facebook utilizza lo stesso meccanismo migliore che posso dire.

Dopo ulteriori ricerche, questo sembra essere OAuth in azione, e visto che la mia API è basata su .Net, sto pensando che dovrei usare DotNetOpenAuth e fornire un meccanismo simile. Sfortunatamente i campioni sono scarsamente documentati (se non del tutto) e gli unici tutorial che posso trovare online sembrano focalizzati sull'aiutarti a fornire un meccanismo di accesso per i tuoi utenti in modo che possano accedere al tuo sito Web utilizzando un fornitore di terze parti.

Quello che mi piacerebbe davvero fare è che la mia API REST gestisca tutta l'autenticazione di base e la logica aziendale per la mia applicazione Web e che, sotto il cofano, la mia applicazione Web sia essenzialmente un'altra applicazione che utilizza l'API tramite OAuth. Gli utenti effettuano l'autenticazione sul sito Web direttamente utilizzando il loro nome utente e password o tramite un fornitore di terze parti come MyOpenID o Facebook e quindi il sito Web utilizza in qualche modo il token restituito per autenticarsi rispetto all'API REST.

In pratica sembra che abbia bisogno della mia API per ospitare in qualche modo un servizio OAuth, ma anche che gli utenti utilizzino un servizio OAuth di terze parti. Non posso fare a meno di pensare che non ho abbastanza conoscenza di OAuth per decidere se sto complicando troppo le cose o se quello che sto cercando di fare è un modo buono o cattivo di fare le cose.

Qualcuno può darmi almeno un'ampia panoramica dei passi che devo intraprendere o cosa dovrei guardare per far sì che ciò accada? O indicarmi alcuni tutorial? O esplodere la mia proposta e dirmi che sto andando su questo (dal punto di vista architettonico) tutto sbagliato?

Innanzitutto vorrei sottolineare la differenza tra autenticazione e autorizzazione:

Un utente si autentica sul tuo sito web fornendo alcune credenziali come nome utente + password. OpenID consente di sostituirlo con l' autenticazione dell'utente su un altro servizio, che quindi asserisce l'identità dell'utente sul tuo sito web per conto dell'utente. Il tuo sito si fida del servizio di terze parti (il provider OpenID) e pertanto considera l'utente connesso.

Un servizio o un'applicazione non si autentica sul tuo sito web, almeno non in genere. Un utente autorizza un servizio o un'applicazione ad accedere ai dati dell'utente. Questo viene in genere fatto dall'applicazione che richiede l'autorizzazione del fornitore di servizi, quindi inviando l'utente al fornitore di servizi, dove l'utente si autentica per primo (quindi il fornitore di servizi sa con chi sta parlando) e quindi l'utente dice al sito "sì, va bene per [applicazione] accedere ai miei dati [in qualche modo limitato] ". Da quel momento in poi l'applicazione utilizza un token di autorizzazioneper accedere ai dati dell'utente sul sito del fornitore di servizi. Si noti che l'applicazione non si autentica come se fosse l'utente, ma utilizza un altro codice per assicurare al servizio di essere autorizzato ad accedere ai dati di un determinato utente.

Pertanto, chiarendo questa distinzione, è possibile prendere decisioni sul proprio sito in merito all'autenticazione e all'autorizzazione in modo completamente indipendente. Ad esempio, se desideri che i tuoi utenti siano in grado di accedere con tutti: nome utente + password, OpenID e Facebook, puoi farlo. Una decisione completamente ortogonale è il modo in cui autorizzi le applicazioni (ci sono molti protocolli che puoi usare per questo, OAuth ovviamente è abbastanza popolare).

OpenID è focalizzata sulla user autenticazione . OAuth è focalizzata sulla domanda di autorizzazione . Tuttavia, alcuni servizi come Facebook e Twitter hanno scelto di utilizzare OAuth per l'autenticazione e l' autorizzazione anziché utilizzare OpenID per l'autenticazione e OAuth per l'autorizzazione.

Ora, per il tuo progetto, ti consiglio caldamente di dare un'occhiata al modello di progetto del sito Web ASPIDNET MVC 2 OpenID (C #) disponibile dalla VS Gallery. Immediatamente viene fornito con l'autenticazione OpenID e il supporto del provider di servizi OAuth. Ciò significa che i tuoi utenti possono accedere con OpenID e applicazioni e servizi di terze parti possono utilizzare OAuth per effettuare chiamate API al tuo sito Web e accedere ai dati dell'utente.

Ciò che vorresti aggiungere a questo modello di progetto una volta iniziato è la possibilità per i tuoi utenti di accedere con nome utente + password e OpenID. Inoltre, se vuoi che Facebook e Twitter siano un'opzione per i tuoi utenti, devi implementarlo anche perché non usano lo standard OpenID. Ma il download DotNetOpenAuth include esempi per l'accesso con Twitter e Facebook in modo da avere qualche guida lì.

Ho il sospetto che non avrai molto o niente da fare sul fronte dell'autorizzazione. Viene fornito con OAuth come ho detto prima, e probabilmente sarà sufficiente per te.

Prima di tutto. Devi separare mentalmente qual è la tua API - dai metodi di autenticazione.

L'API è fondamentalmente risorse e metodi per manipolare tali risorse. E puoi avere diversi metodi per autenticare l'accesso alla tua API.

OAuth è uno di questi meccanismi di autenticazione. Essere un fornitore OAuth è fantastico, anche se le specifiche sono un po 'difficili da comprendere, specialmente le parti che hanno a che fare con le firme. Una volta installato OAuth, le applicazioni client di solito si autenticano facilmente, dal momento che ci sono così tante librerie "open source, già realizzate, implementate" nella maggior parte delle lingue.

Pro e contro di OAuth sono stati discussi per un po '. Ma per esprimere la tua opinione ti suggerisco di leggere questa guida definitiva, scritta da Eran Hammer-Lahav , una delle persone responsabili della specifica OAuth.

Le uniche vere alternative a OAuth per quanto la vedo io sono OAuth 2.0 e una semplice autenticazione di base.

A parte questo, stai parlando di autenticare usando Open-ID, identità di Facebook, ecc. Questa è un'altra domanda che devi porti. Ma non rientra davvero nell'ambito delle API e di OAuth. Per me, sembra più una questione di creazione dell'utente nel tuo servizio. Potrei sbagliarmi.