Creazione di un'API Web con Oauth2/OpenID connect

Question

Sto cercando di capire concettualmente e praticamente come eseguire un oauth2 con flusso openID-connect nella mia applicazione web-api, utilizzando Azure AD.

Importantemente, quando viene effettuata una richiesta all'API, desidero conoscere lo che ha effettuato la richiesta da.

mia comprensione attuale è: -

1. Il mio cliente rileverebbe che l'utente non è connesso e reindirizzare a un segno-in.
2. L'utente fornisce le proprie credenziali e viene reindirizzato al client, insieme a un token oauth2.
3. Questo token verrebbe fornito agli endpoint Web-API per qualsiasi richiesta.

Questo è dove diventa torbido per me.

Come utilizzare esattamente questo token per autorizzare l'accesso a una particolare risorsa, determinare chi sta accedendo alla risorsa e qual è il meccanismo che lo fa?

Suppongo che avrei bisogno di riutilizzare il token per effettuare una chiamata all'endpoint utente di Azure AD: se il token era effettivamente valido, l'endpoint AD restituirebbe i dettagli degli utenti, fornendo in tal modo alcuni mezzi determinare che il token è valido e fornire dettagli sull'identità dell'utente. L'autorizzazione all'accesso a una risorsa può essere eseguita tramite l'appartenenza ai gruppi in Azure AD.

MA ...

posso solo supporre questo un problema risolto, e hanno notato l'uso di OWIN middleware come da questo esempio

https://github.com/AzureADSamples/WebApp-WebAPI-OpenIDConnect-DotNet

Ma sono ancora piuttosto incerti su cosa sta succedendo esattamente.

Il servizio fa menzione di ambiti e attestazioni, ma non capisco da dove sono derivati ​​(presumo da un token fornito dal client, ma non sono sicuro). Il servizio deve ricevere informazioni sull'identità nella chiamata.

Il che mi porta a due punti, per questo di essere sicuro -

1. Il token previsto chiamata al servizio avrebbe bisogno di essere assicurati in trasmissione (da qui l'uso di HTTPS) - per prevenire MITM .

2. È necessario firmare il token come - credo usando il client secret o qualcosa del genere - per impedire che le informazioni nel token vengano falsificate.

Qualcuno può aiutarmi a chiarire questo caos confuso?

In particolare -

1. Come è l'identità del chiamante API determinato - è l'identità determinata da una chiamata nel client o il server?

2. Come limitare l'accesso ad alcuni endpoint dell'API in base a un ruolo utente?

3. Cosa devo fare per ottenere questo risultato basandosi sul middleware e sulle librerie esistenti disponibili?

Answer 1

Disclaimer: Questa non è una risposta completa. È fuori dalla mia testa.

OpenID Connect fornisce un livello di identità sopra OAuth. Nel tuo caso, Active Directory fornisce l'autenticazione e restituisce un access_token. Il token di accesso rappresenta un utente autenticato da AD. Se stai facendo OpenID Connect, quindi AD invierà anche un id_token, che potrebbe contenere ulteriori informazioni sull'identità (come compleanno, avatar e quant'altro AD espone.)

Né OpenID Connect né Active Directory hanno nulla a che fare con il i ruoli che la tua app assegna a un utente; i ruoli sono interamente il baluardo della tua app. Assegni i ruoli utente proprio come faresti normalmente; li si assegna allo nameid invece che a un indirizzo email o nome utente. L'app non deve più autenticare l'utente, ma deve assegnare ruoli allo nameid.

Come viene determinata l'identità del chiamante dell'API: l'identità è determinata da una chiamata nel client o nel server?

L'identità è incorporata nello access_token che AD include nella sua risposta. Questo token avrà un nameid in esso che la tua app può associare a un utente e un ruolo. Lo nameid è come un indirizzo email, un nome utente o un altro ID univoco che l'app utilizza per riconoscere l'utente.

Come limitare l'accesso ad alcuni endpoint dell'API in base a un ruolo utente?

Si sceglie. Quando la tua app riceve una richiesta con un particolare access_token, quel token sarà associato a un particolare utente tramite il suo nameid, e potrai assegnare qualsiasi ruolo e diritto a quell'utente. Fondamentalmente, i ruoli associati con un nameid.

Cosa faccio per ottenere praticamente questo facendo ricorso al middleware e alle librerie esistenti disponibili?

There is an unfinished demo here, sebbene non utilizzi Active Directory come provider, utilizza invece un provider interno. Per la demo, il nome utente è shaun e la password è Testing123!. The source code is here.

Qui è the link to the source of another demo, anche se, di nuovo, non utilizza Active Directory come provider, invece utilizza Twitter.

La cosa bella di OAuth e OpenID Connect è che possiamo utilizzare qualsiasi provider di identità che vogliamo, in modo da poter adattare le demo per utilizzare Active Directory.

Answer 2

Oltre alla domanda n. 1 (l'identità è verificata sul lato del servizio) tutte le domande sono molto aperte e richiederebbero una risposta molto lunga. Consiglierei di leggere https://azure.microsoft.com/en-us/documentation/articles/active-directory-authentication-scenarios/ - è una buona introduzione ai flussi sottostanti a molti dei moderni centri di autenticazione, tra cui l'API Web su cui ci si sta concentrando. Una volta letto questo, troverai una serie completa di campioni in https://azure.microsoft.com/en-us/documentation/articles/active-directory-code-samples/ - in particolare, ti suggerisco di studiare l'API Web e quella di autorizzazione per trovare una guida sulle 3 domande che hai elencato. HTH!