Autenticazione servizio REST

Quali sono le migliori pratiche per l'implementazione dell'autenticazione per le apis REST?Autenticazione servizio REST

Utilizzo dell'autenticazione BASIC + SSL o qualcosa come http://tools.ietf.org/html/draft-hammer-http-token-auth-01?

Sono disponibili soluzioni esistenti (per .NET/WebApi)?

2013-02-21 jgauffin

Per semplificare le cose, è possibile passare un token di sicurezza in un'intestazione su ssl. Proteggi il token utilizzando http://msdn.microsoft.com/en-us/library/system.security.cryptography.hmac.aspx – RubbleFord

Una soluzione utilizzando HMAC, http://stackoverflow.com/questions/11775594/how -to-secure-an-asp-net-web-api/11782361 # 1178236, è possibile utilizzare anche Autenticazione modulo per l'API Web –

La risposta su questo dipende dal pubblico per la tua API Web e cosa vuoi autenticare icate esattamente.

Vuoi autenticare un'applicazione client che utilizza l'API?
Si desidera autenticare un utente dalla propria applicazione per recuperare i propri dati all'interno di un'applicazione client (utilizzando l'API)?
Oppure si desidera autenticare sia l'applicazione client che l'utente utilizzando l'applicazione client.

A seconda di ciò che si desidera autenticare, si dispone di più opzioni. Ma tieni sempre presente che è meglio andare con una soluzione solida in cui sono disponibili molte librerie client che reinventare la propria. Non fatelo mai un po ', ma a modo vostro, scegliete un modo di autenticazione, attenetevi ad esso e non infrangere le librerie client.

autenticazione di base: è molto facile da implementare, ma si autenticare un applicazione client con esso, non è un utente. Questo tipo di autenticazione è utile quando è necessaria una relazione di fiducia aziendale e l'autenticazione e la sicurezza non sono la tua prima preoccupazione. Ma non c'è modo di rintracciare una chiamata nella tua API a un determinato utente, solo un'applicazione client. Ovviamente è possibile salvare il nome utente e la password dell'utente in un'applicazione client, ma questa è una cattiva pratica in più di un modo. autenticazione basata

Token: Loro sono molti modi di token di autenticazione, ma quella che sto parlando qui è un unico token per un utente che le copie degli utenti per l'applicazione client per ottenere l'accesso al vostro Api. In questo modo puoi autenticare un utente (chi ha fatto questa chiamata nella mia Api?) Ed è abbastanza facile da creare e utilizzare. Il ritiro è che non è il modo più sicuro, richiede l'interazione dell'utente e che un utente può usare il suo token Api in più di una applicazione. È possibile estendere questo modo di autenticazione con l'autenticazione di base per autenticare un client. Quindi un clientid + clientsecret + token per identificare l'utente. Ma penso che se vuoi farlo, sarebbe meglio dare un'occhiata a Oauth2.

OAuth2: Se si desidera avere pieno accesso all'autenticazione, è possibile procedere in questo modo. È probabilmente il modo più a prova di futuro per andare, ma richiede anche la maggior parte del lavoro (almeno presso il provider di identità/fornitore di risorse lato.L'applicazione client ha un tempo abbastanza semplice per implementare questo con molte librerie client disponibili. Se si utilizza questa modalità di autenticazione (anche basata su token) è possibile autenticare il client e l'utente, senza la necessità di condividere nome utente e password dell'utente.

La mia raccomandazione: sarebbe di andare con l'autenticazione di base se questo si adatta al tuo caso, è facile e insieme a HTTPS è abbastanza sicuro. Se non si adatta, andrei con Oauth2 perché è lo standard più solido e utilizzato (Instagram//Facebook), ti dà molta libertà e con un crescente ecosystem diventa più facile e più facile da implementare. Dopotutto per qualcuno che implementa la tua API è molto più interessante imparare qualcosa su Oauth 2.0, quindi conoscere il modo di fare jgauffin.

Riferimento: Vorrei anche invitarvi a dare un'occhiata al sito Web di Apigee. Le Api sono affar loro e hanno alcune letture interessanti. Uno di questi è un ebook gratuito - Oauth the big picture che ha anche un paragrafo interessante in cui ti chiedono se hai davvero bisogno di Oauth. (Da pagina 16 - è OAuth tutto il necessario per la sicurezza API?)

Per il server-to-server API - API progettate per essere utilizzato solo da un piccolo numero di server - OAuth è eccessivo. Avere un set separato di credenziali di autenticazione per ogni app è una bella funzione di OAuth, ma per l'utilizzo da server a server, la necessità di accedere in modo sicuro utilizzando un browser, o di implementare altri passaggi in OAuth "dance" si mette di mezzo. Invece, è sufficiente utilizzare un semplice standard di sicurezza come l'autenticazione di base HTTP e assegnare una password unica a ciascuna app. L'SSL a due vie è un altro buon approccio, anche se l'approccio ingombrante ha il vantaggio di un'autenticazione più forte e tracciabile. Tuttavia, pensa in anticipo! Queste API saranno realmente utilizzate dai server solo per sempre?

Solutions Exisisting: In qualunque modo si va leastprivilege - Dominick Baier ed i suoi pacchetti Nuget può dare un bel vantaggio iniziale. Implementare basic authentication usando il suo Identitymodel è davvero facile. Inoltre, se desideri disporre di un codice identityserver pronto per l'uso per fornire token, guarda al suo server di identità che fa tutto il possibile. Comunque se decidi di andare per Oauth2 darei anche un'occhiata a DotnetOpenAuth dato che è (imho) un po 'più configurabile e più facile da modificare a tuo piacimento, ma richiede anche più lavoro.

fonte

2013-02-21 13:42:11