Esercitazione: Autenticare e autorizzare gli utenti end-to-end nel Servizio app di Azure

Servizio app di Azure offre un servizio di hosting Web con scalabilità elevata e funzioni di auto-correzione. Il servizio app include anche il supporto predefinito per l'autenticazione e l'autorizzazione degli utenti. Questa esercitazione illustra come proteggere le app con le funzionalità di autenticazione e autorizzazione del servizio app. Viene usata un'app ASP.NET Core con un front-end Angular.js a titolo di esempio. Le funzionalità di autenticazione e autorizzazione del servizio app supportano runtime di tutti i linguaggi e seguendo l'esercitazione si può apprendere come applicarle al linguaggio preferito.

Il Servizio app di Azure offre un servizio di hosting Web con scalabilità elevata e applicazione automatica di patch basato sul sistema operativo Linux. Il servizio app include anche il supporto predefinito per l'autenticazione e l'autorizzazione degli utenti. Questa esercitazione illustra come proteggere le app con le funzionalità di autenticazione e autorizzazione del servizio app. Viene usata un'app ASP.NET Core con un front-end Angular.js a titolo di esempio. Le funzionalità di autenticazione e autorizzazione del servizio app supportano runtime di tutti i linguaggi e seguendo l'esercitazione si può apprendere come applicarle al linguaggio preferito.

Simple authentication and authorization

Illustra anche come proteggere un'app multilivello, accedendo a un'API back-end protetta per conto dell'utente autenticato sia dal codice del server che dal codice del browser.

Advanced authentication and authorization

Questi sono solo alcuni degli scenari di autenticazione e autorizzazione possibili nel servizio app.

Ecco un elenco più completo delle operazioni illustrate nell'esercitazione:

  • Abilitare l'autenticazione e l'autorizzazione predefinite
  • Proteggere le app da richieste non autenticate
  • Usare Azure Active Directory come provider di identità
  • Accedere a un'app remota per conto dell'utente connesso
  • Proteggere le chiamate da servizio a servizio con l'autenticazione tramite token
  • Usare token di accesso dal codice del server
  • Usare token di accesso dal codice del client (browser)

I passaggi illustrati in questa esercitazione possono essere eseguiti in macOS, Linux e Windows.

Se non si ha una sottoscrizione di Azure, creare un account gratuito prima di iniziare.

Prerequisiti

Per completare questa esercitazione:

Creare l'app .NET Core locale

In questo passaggio si configura il progetto .NET Core locale. Lo stesso progetto verrà usato per distribuire un'app per le API back-end e un'app Web front-end.

Clonare ed eseguire l'applicazione di esempio

  1. Usare questi comandi per clonare il repository di esempio ed eseguirlo.

    git clone https://github.com/Azure-Samples/dotnet-core-api
    cd dotnet-core-api
    dotnet run
    
  2. Passare a http://localhost:5000 e provare ad aggiungere, modificare e rimuovere attività.

    ASP.NET Core API running locally

  3. Per arrestare ASP.NET Core, premere Ctrl+C nel terminale.

  4. Assicurarsi che il ramo predefinito sia main .

    git branch -m main
    

    Suggerimento

    La modifica del nome del ramo non è richiesta dal servizio app. Tuttavia, poiché molti repository modificano il ramo predefinito in , questa esercitazione illustra anche come distribuire main un repository da main . Per altre informazioni, vedere Modificare il ramo di distribuzione.

Distribuire le app in Azure

In questo passaggio si distribuisce il progetto in due app del servizio app: una è l'app front-end e l'altra è l'app back-end.

Configurare un utente della distribuzione

FTP e l'istanza Git locale possono essere usati per la distribuzione in un'app Web tramite un utente della distribuzione. Dopo aver configurato l'utente della distribuzione, è possibile usarlo per tutte le distribuzioni di Azure. Il nome utente e la password della distribuzione a livello di account sono diversi dalle credenziali della sottoscrizione di Azure.

Per configurare l'utente della distribuzione, eseguire il comando az webapp deployment user set in Azure Cloud Shell. Sostituire < nome utente e password con un nome utente e una password ><> dell'utente della distribuzione.

  • Il nome utente deve essere univoco in Azure e per i push Git locali non deve contenere il simbolo "\@".
  • La password deve essere composta da almeno otto caratteri, con due dei tre elementi seguenti: lettere, numeri e simboli.
az webapp deployment user set --user-name <username> --password <password>

L'output JSON mostra la password come null. Se viene visualizzato un errore 'Conflict'. Details: 409, modificare il nome utente. Se viene visualizzato un errore 'Bad Request'. Details: 400, usare una password più complessa.

Registrare il nome utente e la password da usare per distribuire le app Web.

Creare le risorse di Azure

In Cloud Shell eseguire questi comandi per creare due app Web Windows. Sostituire front-end-app-name > e > con due nomi di app univoci a livello globale (i caratteri validi a-z sono , e 0-9- ). Per altre informazioni su ogni comando, vedere Ospitare un'API RESTfulcon CORS in Servizio app di Azure .

az group create --name myAuthResourceGroup --location "West Europe"
az appservice plan create --name myAuthAppServicePlan --resource-group myAuthResourceGroup --sku FREE
az webapp create --resource-group myAuthResourceGroup --plan myAuthAppServicePlan --name <front-end-app-name> --deployment-local-git --query deploymentLocalGitUrl
az webapp create --resource-group myAuthResourceGroup --plan myAuthAppServicePlan --name <back-end-app-name> --deployment-local-git --query deploymentLocalGitUrl

In Cloud Shell eseguire questi comandi per creare due app Web. Sostituire front-end-app-name > e > con due nomi di app univoci a livello globale (i caratteri validi a-z sono , e 0-9- ). Per altre informazioni su ogni comando, vedere Creare un'app .NET Core nel Servizio app di Azure.

az group create --name myAuthResourceGroup --location "West Europe"
az appservice plan create --name myAuthAppServicePlan --resource-group myAuthResourceGroup --sku FREE --is-linux
az webapp create --resource-group myAuthResourceGroup --plan myAuthAppServicePlan --name <front-end-app-name> --runtime "DOTNETCORE|3.1" --deployment-local-git --query deploymentLocalGitUrl
az webapp create --resource-group myAuthResourceGroup --plan myAuthAppServicePlan --name <back-end-app-name> --runtime "DOTNETCORE|3.1" --deployment-local-git --query deploymentLocalGitUrl

Nota

Salvare gli URL degli elementi Git remoti per l'app front-end e l'app back-end, riportati nell'output di az webapp create.

Effettuare il push in Azure da Git

  1. Poiché si distribuisce il ramo, è necessario impostare il ramo di distribuzione predefinito per le due app del servizio main app su main (vedere Modificare il ramo di main). Nella finestra Cloud Shell impostare DEPLOYMENT_BRANCH l'app con il az webapp config appsettings set comando .

    az webapp config appsettings set --name <front-end-app-name> --resource-group myAuthResourceGroup --settings DEPLOYMENT_BRANCH=main
    az webapp config appsettings set --name <back-end-app-name> --resource-group myAuthResourceGroup --settings DEPLOYMENT_BRANCH=main
    
  2. Nella finestra del terminale locale eseguire questi comandi Git per la distribuzione nell'app back-end. Sostituire deploymentLocalGitUrl-of-back-end-app > con l'URL del remoto Git salvato > Quando Git Credential Manager richiede le credenziali, assicurarsi di immettere le credenziali per la distribuzione e non quelle usate per accedere al portale di Azure.

    git remote add backend <deploymentLocalGitUrl-of-back-end-app>
    git push backend main
    
  3. Nella finestra del terminale locale eseguire questi comandi Git per distribuire lo stesso codice nell'app front-end. Sostituire deploymentLocalGitUrl-of-front-end-app > con l'URL del remoto Git salvato >

    git remote add frontend <deploymentLocalGitUrl-of-front-end-app>
    git push frontend main
    

Passare alle app

Passare agli URL seguenti in un browser e visualizzare le due app in esecuzione.

http://<back-end-app-name>.azurewebsites.net
http://<front-end-app-name>.azurewebsites.net

Screenshot of an Azure App Service Rest API Sample in a browser window, which shows a To do list app.

Nota

Se l'app viene riavviata, si noterà che sono stati cancellati nuovi dati. Questo comportamento è determinato dalla progettazione, perché l'app ASP.NET Core usa un database in memoria.

Chiamare l'API back-end dal front-end

In questo passaggio si definisce il codice del server dell'app front-end per l'accesso all'API back-end. Successivamente si abiliterà l'accesso autenticato dal front-end al back-end.

Modificare il codice del front-end

  1. Nel repository locale aprire Controllers/TodoController.cs. All'inizio della classe aggiungere le righe TodoController seguenti e sostituire TodoController con il nome dell'app back-end:

    private static readonly HttpClient _client = new HttpClient();
    private static readonly string _remoteUrl = "https://<back-end-app-name>.azurewebsites.net";
    
  2. Trovare il metodo decorato con [HttpGet] e sostituire il codice all'interno delle parentesi graffe con:

    var data = await _client.GetStringAsync($"{_remoteUrl}/api/Todo");
    return JsonConvert.DeserializeObject<List<TodoItem>>(data);
    

    La prima riga effettua una chiamata GET /api/Todo all'app per le API back-end.

  3. Trovare quindi il metodo decorato con [HttpGet("{id}")] e sostituire il codice all'interno delle parentesi graffe con:

    var data = await _client.GetStringAsync($"{_remoteUrl}/api/Todo/{id}");
    return Content(data, "application/json");
    

    La prima riga effettua una chiamata GET /api/Todo/{id} all'app per le API back-end.

  4. Trovare quindi il metodo decorato con [HttpPost] e sostituire il codice all'interno delle parentesi graffe con:

    var response = await _client.PostAsJsonAsync($"{_remoteUrl}/api/Todo", todoItem);
    var data = await response.Content.ReadAsStringAsync();
    return Content(data, "application/json");
    

    La prima riga effettua una chiamata POST /api/Todo all'app per le API back-end.

  5. Trovare quindi il metodo decorato con [HttpPut("{id}")] e sostituire il codice all'interno delle parentesi graffe con:

    var res = await _client.PutAsJsonAsync($"{_remoteUrl}/api/Todo/{id}", todoItem);
    return new NoContentResult();
    

    La prima riga effettua una chiamata PUT /api/Todo/{id} all'app per le API back-end.

  6. Trovare quindi il metodo decorato con [HttpDelete("{id}")] e sostituire il codice all'interno delle parentesi graffe con:

    var res = await _client.DeleteAsync($"{_remoteUrl}/api/Todo/{id}");
    return new NoContentResult();
    

    La prima riga effettua una chiamata DELETE /api/Todo/{id} all'app per le API back-end.

  7. Salvare tutte le modifiche. Nella finestra del terminale locale distribuire le modifiche nell'app front-end con i comandi Git seguenti:

    git add .
    git commit -m "call back-end API"
    git push frontend main
    

Verificare le modifiche

  1. Passare a http://<front-end-app-name>.azurewebsites.net e aggiungere alcuni elementi, ad esempio from front end 1 e from front end 2.

  2. Passare a http://<back-end-app-name>.azurewebsites.net per visualizzare gli elementi aggiunti dall'app front-end. Aggiungere anche alcuni elementi, ad esempio from back end 1 e from back end 2, quindi aggiornare l'app front-end per verificare se riflette le modifiche.

    Screenshot of an Azure App Service Rest API Sample in a browser window, which shows a To do list app with items added from the front-end app.

Configurare l'autenticazione e l'autorizzazione

In questo passaggio si abilitano l'autenticazione e l'autorizzazione per le due app. Si configura anche l'app front-end per generare un token di accesso che potrà essere usato per effettuare chiamate autenticate all'app back-end.

Come provider di identità viene usato Azure Active Directory. Per altre informazioni, vedere Configurare l'autenticazione di Azure Active Directory per un'applicazione dei servizi app.

Abilitare l'autenticazione e l'autorizzazione per l'app back-end

  1. Nel menu del portale di Azure selezionare Gruppi di risorse oppure cercare e selezionare Gruppi di risorse da qualsiasi pagina.

  2. In Gruppi di risorse cercare e selezionare il gruppo di risorse desiderato. In Panoramica selezionare la pagina di gestione dell'app back-end.

    Screenshot of the Resource groups window, showing the Overview for an example resource group and a back-end app's management page selected.

  3. Nel menu a sinistra dell'app back-end selezionare Autenticazionee quindi fare clic su Aggiungi provider di identità.

  4. Nella pagina Aggiungi un provider di identità selezionare Microsoft come provider di identità per accedere a Microsoft e Azure AD identità.

  5. Accettare le impostazioni predefinite e fare clic su Aggiungi.

    Screenshot of the back-end app's left menu showing Authentication/Authorization selected and settings selected in the right menu.

  6. Verrà visualizzata la pagina Autenticazione. Copiare l'ID client dell'applicazione di Azure AD negli appunti. Questo valore sarà necessario in un secondo momento.

    Screenshot of the Azure Active Directory Settings window showing the Azure AD App, and the Azure AD Applications window showing the Client ID to copy.

Se ci si ferma qui, si avrà un'app autonoma che è già protetta dall'autenticazione e dall'autorizzazione del servizio app. Le sezioni rimanenti illustrano come proteggere una soluzione di più app "propagando" l'utente autenticato dal front-end al back-end.

Abilitare l'autenticazione e l'autorizzazione per l'app front-end

Seguire la stessa procedura per l'app front-end, ignorando però l'ultimo passaggio. Per l'app front-end non è necessario l'ID client. Tuttavia, rimanere nella pagina Autenticazione per l'app front-end perché verrà utilizzata nel passaggio successivo.

Se si vuole, passare a http://<front-end-app-name>.azurewebsites.net. Si verrà indirizzati a una pagina di accesso protetta. Dopo aver eseguito l'accesso, non è ancora possibile accedere ai dati dall'app back-end perché l'app back-end richiede ora l'accesso di Azure Active Directory dall'app front-end. È necessario eseguire tre operazioni:

  • Concedere al front-end l'accesso al back-end
  • Configurare il servizio app per la restituzione di un token utilizzabile
  • Usare il token nel codice

Suggerimento

Se si verificano errori e le impostazioni di autenticazione/autorizzazione dell'app vengono riconfigurate, i token nell'archivio token potrebbero non essere rigenerati dalle nuove impostazioni. Per assicurarsi che i token vengano rigenerati, è necessario disconnettersi e accedere di nuovo all'app. Un modo semplice per eseguire tale operazione consiste nell'usare il browser in modalità privata, chiudendo e riaprendo il browser in modalità privata dopo aver modificato le impostazioni nelle app.

Concedere all'app front-end l'accesso al back-end

Dopo l'abilitazione dell'autenticazione e dell'autorizzazione per entrambe le app, ognuna di queste è supportata da un'applicazione AD. In questo passaggio si concedono all'app front-end le autorizzazioni necessarie per accedere al back-end per conto dell'utente. Tecnicamente, si concedono all'applicazione AD del front-end le autorizzazioni per accedere all'applicazione AD del back-end per conto dell'utente.

  1. Nella pagina Autenticazione per l'app front-end selezionare il nome dell'app front-end in Provider di identità. La registrazione dell'app è stata generata automaticamente. Selezionare Autorizzazioni API nel menu a sinistra.

  2. Selezionare Add a permission (Aggiungi un'autorizzazione)e quindi My APIs back-end-app-name (Api my back-end-app-name).

  3. Nella pagina Richiedi le autorizzazioni dell'API per l'app back-end, selezionare Autorizzazioni delegate e user_impersonation, quindi selezionare Aggiungere autorizzazioni.

    Screenshot of the Request API permissions page showing Delegated permissions, user_impersonation, and the Add permission button selected.

Configurare il servizio app per la restituzione di un token di accesso utilizzabile

L'app front-end ha ora le autorizzazioni necessarie per accedere all'app back-end come utente connesso. In questo passaggio si configurano l'autenticazione e l'autorizzazione del servizio app affinché forniscano un token di accesso utilizzabile per accedere al back-end. Per questo passaggio è necessario l'ID client del back-end copiato in Abilitare l'autenticazione e l'autorizzazione per l'app back-end.

Nell'Cloud Shell eseguire i comandi seguenti nell'app front-end per aggiungere il parametro scope all'impostazione di autenticazione identityProviders.azureActiveDirectory.login.loginParameters . Sostituire front-end-app-name e >>.

authSettings=$(az webapp auth show -g myAuthResourceGroup -n <front-end-app-name>)
authSettings=$(echo "$authSettings” | jq '.properties' | jq '.identityProviders.azureActiveDirectory.login += {"loginParameters":["scope=openid profile email offline_access api://<back-end-client-id>/user_impersonation"]}')
az webapp auth set --resource-group myAuthResourceGroup --name <front-end-app-name> --body "$authSettings"

I comandi aggiungono in modo loginParameters efficace una proprietà con ambiti personalizzati aggiuntivi. Ecco una spiegazione degli ambiti richiesti:

  • openid, profile e sono già richiesti dal servizio app per impostazione email predefinita. Per informazioni, vedere Ambiti Connessione OpenID.
  • api://<back-end-client-id>/user_impersonation è un'API esposta nella registrazione dell'app back-end. È l'ambito che fornisce un token JWT che include l'app back-end come destinatario del token.
  • offline_access è incluso qui per praticità (nel caso in cui si voglia aggiornare i token).

Suggerimento

  • Per visualizzare l'ambito nel portale di Azure, passare alla pagina Autenticazione per api://<back-end-client-id>/user_impersonation l'app back-end, fare clic sul collegamento in Providerdi identità e quindi fare clic su Esporre un'API nel menu a sinistra. api://<back-end-client-id>/user_impersonation
  • Per configurare gli ambiti necessari usando invece un'interfaccia Web, vedere i passaggi di Microsoft in Aggiornare i token di autenticazione.
  • Alcuni ambiti richiedono il consenso dell'amministratore o dell'utente. Questo requisito determina la visualizzazione della pagina di richiesta di consenso quando un utente accede all'app front-end nel browser. Per evitare questa pagina di consenso, aggiungere la registrazione dell'app del front-end come applicazione client autorizzata nella pagina Esporre un'API facendo clic su Aggiungi un'applicazione client e fornendo l'ID client della registrazione dell'app del front-end.

Nota

Per le app Linux, esiste un requisito temporaneo per configurare un'impostazione di controllo delle versioni per la registrazione dell'app back-end. Nel Cloud Shell configurarlo con i comandi seguenti. Assicurarsi di sostituire back-end-client-id > con l'ID client del back-end.

id=$(az ad app show --id <back-end-client-id> --query objectId --output tsv)
az rest --method PATCH --url https://graph.microsoft.com/v1.0/applications/$id --body "{'api':{'requestedAccessTokenVersion':2}}" 

Le app sono ora configurate. Il front-end è pronto per accedere al back-end con un token di accesso appropriato.

Per informazioni su come configurare il token di accesso per altri provider, vedere Aggiornare i token del provider di identità.

Chiamare l'API in modo sicuro dal codice del server

In questo passaggio si abilita il codice del server modificato in precedenza per effettuare chiamate autenticate all'API back-end.

L'app front-end ha ora l'autorizzazione necessaria e aggiunge inoltre l'ID client del back-end ai parametri di accesso. Può quindi ottenere un token di accesso per l'autenticazione con l'app back-end. Il servizio app fornisce questo token al codice del server tramite l'inserimento di un'intestazione a ogni richiesta autenticata X-MS-TOKEN-AAD-ACCESS-TOKEN (vedere X-MS-TOKEN-AAD-ACCESS-TOKEN

Nota

Queste intestazioni vengono inserite per tutti i linguaggi supportati. Per accedervi, usare il modello standard per il rispettivo linguaggio.

  1. Nel repository locale aprire di nuovo Controllers/TodoController.cs. Sotto il costruttore TodoController(TodoContext context) aggiungere il codice seguente:

    public override void OnActionExecuting(ActionExecutingContext context)
    {
        base.OnActionExecuting(context);
    
        _client.DefaultRequestHeaders.Accept.Clear();
        _client.DefaultRequestHeaders.Authorization =
            new AuthenticationHeaderValue("Bearer", Request.Headers["X-MS-TOKEN-AAD-ACCESS-TOKEN"]);
    }
    

    Questo codice aggiunge l'intestazione HTTP standard Authorization: Bearer <access-token> a tutte le chiamate ad API remote. Nella pipeline di esecuzione della richiesta ASP.NET Core MVC OnActionExecuting viene eseguito subito prima dell'azione, di conseguenza ogni chiamata API in uscita presenta ora il token di accesso.

  2. Salvare tutte le modifiche. Nella finestra del terminale locale distribuire le modifiche nell'app front-end con i comandi Git seguenti:

    git add .
    git commit -m "add authorization header for server code"
    git push frontend main
    
  3. Accedere di nuovo a https://<front-end-app-name>.azurewebsites.net. Nella pagina del contratto per l'utilizzo dei dati utente fare clic su Accetta.

    Dovrebbe ora essere possibile creare, leggere, aggiornare ed eliminare i dati dell'app back-end come prima. L'unica differenza consiste nel fatto che ora entrambe le app, incluse le chiamate da servizio a servizio, sono protette dall'autenticazione e dall'autorizzazione del servizio app.

Congratulazioni! Il codice del server accede ora ai dati del back-end per conto dell'utente autenticato.

Chiamare l'API in modo sicuro dal codice del browser

In questo passaggio si configura l'app Angular.js front-end in modo che punti all'API back-end. In questo modo si apprenderà come recuperare il token di accesso ed effettuare chiamate API all'app back-end con tale token.

Anche se il codice server ha accesso alle intestazioni della richiesta, il codice client può accedere per ottenere gli stessi token di accesso GET /.auth/me (vedere GET /.auth/me

Suggerimento

Questa sezione illustra le chiamate HTTP sicure usando i metodi HTTP standard. È tuttavia possibile usare Microsoft Authentication Library per JavaScript per semplificare il modello di applicazione Angular.js.

Configurare CORS

In Cloud Shell abilitare CORS per l'URL del client usando il comando az webapp cors add. Sostituire i segnaposto back-end-app-name > e >

az webapp cors add --resource-group myAuthResourceGroup --name <back-end-app-name> --allowed-origins 'https://<front-end-app-name>.azurewebsites.net'

Questo passaggio non è correlato all'autenticazione e all'autorizzazione. È tuttavia necessario affinché il browser consenta chiamate API tra domini dall'app Angular.js. Per altre informazioni, vedere Aggiungere funzionalità CORS.

Puntare l'app Angular.js all'API back-end

  1. Nel repository locale aprire wwwroot/index.html.

  2. A riga 51 impostare la variabile apiEndpoint sull'URL HTTPS dell'app back-end (https://<back-end-app-name>.azurewebsites.net). Sostituire back-end-app-name con > il nome dell'app nel servizio app.

  3. Nel repository locale aprire wwwroot/app/scripts/todoListSvc.js e verificare che sia anteposto a tutte le chiamate API. L'app Angular.js chiama ora le API back-end.

Aggiungere il token di accesso alle chiamate API

  1. In wwwroot/app/scripts/todoListSvc.js, sopra l'elenco delle chiamate API (sopra la riga ), aggiungere la funzione seguente all'elenco:

    setAuth: function (token) {
        $http.defaults.headers.common['Authorization'] = 'Bearer ' + token;
    },
    

    Questa funzione viene chiamata per impostare l'intestazione Authorization predefinita con il token di accesso. Verrà chiamata nel passaggio successivo.

  2. Nel repository locale aprire wwwroot/app/scripts/app.js e trovare il codice seguente:

    $routeProvider.when("/Home", {
        controller: "todoListCtrl",
        templateUrl: "/App/Views/TodoList.html",
    }).otherwise({ redirectTo: "/Home" });
    
  3. Sostituire l'intero blocco di codice con il codice seguente:

    $routeProvider.when("/Home", {
        controller: "todoListCtrl",
        templateUrl: "/App/Views/TodoList.html",
        resolve: {
            token: ['$http', 'todoListSvc', function ($http, todoListSvc) {
                return $http.get('/.auth/me').then(function (response) {
                    todoListSvc.setAuth(response.data[0].access_token);
                    return response.data[0].access_token;
                });
            }]
        },
    }).otherwise({ redirectTo: "/Home" });
    

    La nuova modifica aggiunge il mapping resolve, che chiama /.auth/me e imposta il token di accesso. Viene così garantita la disponibilità del token di accesso prima della creazione di un'istanza del controller todoListCtrl. In questo modo, tutte le chiamate API da parte del controller includeranno il token.

Distribuire aggiornamenti ed eseguire un test

  1. Salvare tutte le modifiche. Nella finestra del terminale locale distribuire le modifiche nell'app front-end con i comandi Git seguenti:

    git add .
    git commit -m "add authorization header for Angular"
    git push frontend main
    
  2. Passare di nuovo a https://<front-end-app-name>.azurewebsites.net. Dovrebbe ora essere possibile creare, leggere, aggiornare ed eliminare i dati dell'app back-end direttamente nell'app Angular.js.

Congratulazioni! Il codice del client accede ora ai dati del back-end per conto dell'utente autenticato.

Quando scadono i token di accesso

Il token di accesso scade dopo un certo periodo di tempo. Per informazioni su come aggiornare i token di accesso senza chiedere agli utenti di autenticarsi di nuovo nell'app, vedere Refresh identity provider tokens (Aggiornare i token del provider di identità).

Pulire le risorse

Nei passaggi precedenti sono state create risorse di Azure in un gruppo di risorse. Se si ritiene che queste risorse non saranno necessarie in futuro, eliminare il gruppo di risorse eseguendo questo comando in Cloud Shell:

az group delete --name myAuthResourceGroup

L'esecuzione del comando può richiedere un minuto.

Passaggi successivi

Contenuto dell'esercitazione:

  • Abilitare l'autenticazione e l'autorizzazione predefinite
  • Proteggere le app da richieste non autenticate
  • Usare Azure Active Directory come provider di identità
  • Accedere a un'app remota per conto dell'utente connesso
  • Proteggere le chiamate da servizio a servizio con l'autenticazione tramite token
  • Usare token di accesso dal codice del server
  • Usare token di accesso dal codice del client (browser)

Passare all'esercitazione successiva per apprendere come eseguire il mapping di un nome DNS personalizzato all'app.