2015-01-12 24 views
6

Sto postando questo nella speranza di ricevere feedback/consigli e informazioni su qualcosa che ho avuto difficoltà negli ultimi giorni. Per iniziare darò una rapida ripartizione del progetto.Autorizzazione con token bearer OAuth fornito da API Web esterna

ci sono 2 applicazioni nella soluzione:

  1. WebAPI risorse & server di autorizzazione - Utilizza OWIN (ospitato in IIS) e ASP.NET identità di emettere un token di autenticazione su un corretto login e poi consentire le richieste ai vari controllori.

  2. Applicazione client MVC - Non ha ancora alcuna autorizzazione (fino a quando non l'ho capito) ma effettuerà chiamate al server di risorse WebAPI per ottenere tutti i dati. Queste chiamate verranno sempre e solo effettuate da azioni dei controller nell'app client, senza chiamate AJAX lato client.

L'applicazione client non ha il proprio datasource. Tutte le informazioni sono memorizzate in un database a cui il servizio WebAPI ha accesso, quindi in sostanza se forniscono le credenziali corrette e l'app client riceve un token al portatore, devo fornire un modo affinché l'applicazione possa vederle come autorizzate.

  • Qual è il modo migliore per gestire questo?
  • È possibile configurare OWIN sul lato client per utilizzare le impostazioni OAuth del server? Sto abbaiando dall'albero sbagliato e dovrò semplicemente usare HTTPClients?
  • Posso deserializzare il token al portatore e memorizzarlo in sessione e quindi scrivere i miei provider di autorizzazione per controllarli dal lato client?

Le mie preoccupazioni iniziali sono che sto abusando di token bearer e cercando di trasformarli in una soluzione che non è l'ideale. Tutti gli esempi di autorizzazione esterna che ho trovato finora implicano solitamente effettuare chiamate a provider ospitati da Google/Facebook/Twitter per verificare che l'utente sia chi dicono di essere e quindi passare alla creazione di un record utente nel proprio sistema. La mia domanda non può farlo.

Per quanto riguarda la sicurezza, stavo progettando di introdurre i filtri che avrebbero convalidato la richiesta proveniente dall'applicazione client fornendo un identificatore e un segreto, insieme alla convalida IP.

Mi rendo conto che potrebbe essere un po 'aperto, ma gradirei qualsiasi consiglio. Lo scopo del progetto è che il servizio Web è la cosa solo per accedere al database. L'applicazione client MVC verrà ospitata su un server diverso e il servizio accetterà solo le richieste da tale applicazione client.

+0

buona domanda .... –

risposta

5

Non è necessario accedere all'origine dati nell'app MVC per convalidare il token al portatore. In sostanza, si può fare in questo modo,

  • MVC app richiede access_token da WebAPI e lo passa al client dell'interfaccia utente (diciamo un browser).

  • Il browser memorizza access_token in un cookie/localstorage e li invia all'app MVC per tutte le richieste successive.

  • Creare un ActionFilter nell'app MVC per convalidare se la richiesta dal browser ha il token fornito nell'intestazione. In caso contrario, respingere la richiesta.

  • L'app MVC supera access_token nell'intestazione Authorization sul webapi.

  • utilizzare HTTPS per tutte le comunicazioni (tra MVC app < -> Cliente e MVC app < -> WebAPI)

È possibile inoltre nascondere o cifrare il access_token si ottiene dalla WebAPI sul MVC app lato per ulteriore sicurezza, ma poi dovrai inviare la versione decrittografata alla WebAPI.

+0

Grazie per il tuo commento. HTTPS verrà utilizzato nella versione di produzione. Dove sto lottando è capire come implementare la sicurezza di base nell'applicazione client. Mi piacerebbe (se possibile) utilizzare alcune delle funzionalità esistenti come Autorizza attributo, AllowAnonymous, ecc. My WebAPI può farlo in quanto ha il proprio archivio utente e gestore, ma quale sarebbe la soluzione migliore per aggiungere l'autorizzazione all'app client che non lo fa? – CannonFodder

+0

L'app del client MVC non deve convalidare il token al portatore. È sufficiente verificare se nella richiesta è presente un token (questa è la sicurezza di base che è possibile implementare dal lato dell'app MVC). Puoi farlo creando un ActionFilter e usandolo proprio come l'attributo Authorize. – su8898

+0

Penso che abbia senso. Non avevo intenzione di convalidare il token al portatore. Il piano era di prenderlo, conservarlo in sessione, verificarne l'esistenza e quindi gestire la richiesta da lì. Se è scaduto o così chiederò loro di ri-autenticarsi o esaminare i token di aggiornamento. Questo è tutto un po 'nuovo per me, quindi la mia preoccupazione principale era che forse stavo trascurando qualche difetto. Penso che tu abbia risposto alla mia domanda. – CannonFodder

3

mi rendo conto che la mia risposta è un po 'tardi, ma forse aiuta altre persone:

Il token portatore che si ottiene dalla API ha un elenco di indicazioni crittografati che solo l'API può decifrare. Presumo che sia necessario avere queste affermazioni anche sull'applicazione MVC in modo da poter limitare le risorse sul client.

Quindi, quello che ho fatto è stato ottenere il token. Dopo averlo ottenuto, si effettua un'altra richiesta alla risorsa API api/me/afferma di ottenere l'elenco delle attestazioni leggibili sul client. Sulla base di questo elenco è possibile consentire l'accesso alle risorse nella propria applicazione CLC MVC utilizzando un attributo Autorizza basato su attestazioni personalizzate. Inoltre, è possibile memorizzare le attestazioni in un cookie nella sessione client. Di seguito è riportato il codice per il controller API per ottenere i reclami.

[RoutePrefix("api/me/claims")] 
public class ClaimsController : BaseApiController 
{ 
    [Authorize] 
    [Route("")] 
    public IHttpActionResult GetClaims() 
    { 
     var identity = User.Identity as ClaimsIdentity; 

     var claims = from c in identity.Claims 
        select new 
        { 
         subject = c.Subject.Name, 
         type = c.Type, 
         value = c.Value 
        }; 

     return Ok(claims); 
    } 
} 

L'idea è quella di ricostruire l'oggetto ClaimsIdentity dell'utente connesso sul lato client e magari aggiungerlo alla sessione.

Il token non è sufficiente. Potresti rischiare di ottenere una risposta non autorizzata dall'API su una risorsa che hai reso visibile all'utente nell'applicazione client MVC. Aghi per dire che si consiglia di utilizzare HTTPS per tutte le richieste.

Problemi correlati