Zelfstudie: Zelfstudie: Gebruikers eind-tot-eind verifiëren en autoriseren in Azure App Service

Azure App Service biedt een uiterst schaalbare webhostingservice met self-patchfunctie. Daarnaast bevat App Service ingebouwde ondersteuning voor verificatie en autorisatie van gebruikers. In deze zelfstudie leest u hoe u apps kunt beveiligen met verificatie en autorisatie van App Service. Als voorbeeld wordt gebruikgemaakt van een ASP.NET Core-app met een Angular.js-front-end. Verificatie en autorisatie van App Service ondersteunt runtime voor alle talen en u leert hoe u deze kunt toepassen op uw taal van voorkeur door de zelfstudie te volgen.

Azure App Service biedt een uiterst schaalbare webhostingservice met self-patchfunctie via het Linux-besturingssysteem. Daarnaast bevat App Service ingebouwde ondersteuning voor verificatie en autorisatie van gebruikers. In deze zelfstudie leest u hoe u apps kunt beveiligen met verificatie en autorisatie van App Service. Als voorbeeld wordt gebruikgemaakt van een ASP.NET Core-app met een Angular.js-front-end. Verificatie en autorisatie van App Service ondersteunt runtime voor alle talen en u leert hoe u deze kunt toepassen op uw taal van voorkeur door de zelfstudie te volgen.

Simple authentication and authorization

U leest ook hoe u een app met meerdere lagen beveiligt door namens de geverifieerde gebruiker een beveiligde back-end-API te openen, zowel door middel van servercode als browsercode.

Advanced authentication and authorization

Dit zijn slechts enkele van de mogelijke scenario's voor verificatie en autorisatie in App Service.

Hieronder vindt u een meer uitgebreide lijst met zaken die u in de zelfstudie leert:

  • Ingebouwde verificatie en autorisatie inschakelen
  • Apps beveiligen tegen niet-geverifieerde aanvragen
  • Azure Active Directory gebruiken als id-provider
  • Externe apps openen namens de aangemelde gebruiker
  • Aanroepen tussen services beveiligen met tokenverificatie
  • Toegangstokens gebruiken vanuit servercode
  • Toegangstokens gebruiken vanuit clientcode (browser)

U kunt de stappen in deze zelfstudie volgen voor macOS, Linux en Windows.

Als u geen Azure-abonnement hebt,maakt u een gratis Azure-account voordat u begint.

Vereisten

Vereisten voor het voltooien van deze zelfstudie:

  • Gebruik de Bash-omgeving in Azure Cloud Shell. Zie voor meer informatie Azure Cloud Shell Quickstart - Bash.

    Launch Cloud Shell in a new window

  • Als u liever CLI-referentieopdrachten lokaal wilt uitvoeren, installeert u de Azure CLI. Als u op een Windows of macOS, kunt u Azure CLI uitvoeren in een Docker-container. Zie De Azure CLI uitvoeren in een Docker-containervoor meer informatie.

    • Als u een lokale installatie gebruikt, meldt u zich aan bij Azure CLI met behulp van de opdracht AZ login. Volg de stappen die worden weergegeven in de terminal, om het verificatieproces te voltooien. Raadpleeg Aanmelden bij de Azure CLI voor aanvullende aanmeldingsopties.

    • Installeer de Azure CLI-extensie bij het eerste gebruik, wanneer u hierom wordt gevraagd. Raadpleeg Extensies gebruiken met Azure CLI voor meer informatie over extensies.

    • Voer az version uit om de geïnstalleerde versie en afhankelijke bibliotheken te vinden. Voer az upgrade uit om te upgraden naar de nieuwste versie.

Lokale .NET Core-app maken

In deze stap stelt u het lokale .NET Core-project in. U gebruikt hetzelfde project voor het implementeren van een back-end-API-app en een front-end-web-app.

De voorbeeldtoepassing klonen en uitvoeren

  1. Voer de volgende opdrachten uit om de voorbeeldopslagplaats te klonen en voer deze uit.

    git clone https://github.com/Azure-Samples/dotnet-core-api
    cd dotnet-core-api
    dotnet run
    
  2. Ga naar http://localhost:5000 en voeg taken toe, bewerk deze en verwijder ze.

    ASP.NET Core API running locally

  3. Als u de ASP.NET Core, drukt u Ctrl+C in de terminal.

  4. Zorg ervoor dat de standaard branch main is.

    git branch -m main
    

    Tip

    De naamswijziging van de vertakking is niet vereist door App Service. Omdat veel opslagplaatsen hun standaardvertakking echter wijzigen in , laat deze zelfstudie u ook zien hoe u een opslagplaats main implementeert vanuit main . Zie Change deployment branch (Implementatiebranche wijzigen) voor meer informatie.

Apps in Azure implementeren

In deze stap implementeert u het project in twee App Service-apps. De ene is de front-end-app en de andere is de back-end-app.

Een implementatiegebruiker configureren

FTP en lokale Git kunnen worden geïmplementeerd in een Azure-web-app met behulp van een implementatiegebruikers. Zodra u deze implementatiegebruiker hebt gemaakt, kunt u deze voor al uw Azure-implementaties gebruiken. Uw gebruikersnaam en wachtwoord voor implementatie op accountniveau verschillen van de referenties voor uw Azure-abonnement.

Als u de implementatiegebruiker wilt configureren, voert u de opdracht az webapp deployment user set uit in Azure Cloud Shell. Vervang gebruikersnaam en wachtwoord door de gebruikersnaam en het wachtwoord <> van de <> implementatiegebruiker.

  • De gebruikersnaam moet uniek zijn binnen Azure en voor lokale Git-pushes en mag het symbool @ niet bevatten.
  • Het wachtwoord moet ten minste acht tekens lang zijn en minimaal twee van de volgende drie typen elementen bevatten: letters, cijfers en symbolen.
az webapp deployment user set --user-name <username> --password <password>

De JSON-uitvoer toont het wachtwoord als null. Als er een 'Conflict'. Details: 409-fout optreedt, wijzigt u de gebruikersnaam. Als er een 'Bad Request'. Details: 400-fout optreedt, kiest u een sterker wachtwoord.

Noteer uw gebruikersnaam en wachtwoord om te gebruiken bij het implementeren van uw web-apps.

Azure-resources maken

Voer in Azure Cloud Shell de volgende opdrachten uit om twee Windows-web-apps te maken. Vervang front-end-app-name > en > door twee globaal unieke app-namen (geldige tekens a-z zijn , en 0-9- ). Zie Host a RESTful API with CORS inAzure App Service (Een RESTful API hosten met CORS in Azure App Service) voor meer informatie over Azure App Service.

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

Voer in Azure Cloud Shell de volgende opdrachten uit om twee web-apps te maken. Vervang front-end-app-name > en > door twee globaal unieke app-namen (geldige tekens a-z zijn , en 0-9- ). Zie Een .NET Core-app maken in Azure App Service voor meer informatie over elke opdracht.

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

Notitie

Sla de URL's van de externe Git-instanties voor de front-en-app en de back-end-app op. Deze worden in de uitvoer van az webapp create weergegeven.

Pushen naar Azure vanaf Git

  1. Omdat u de vertakking implementeert, moet u de standaardimplementatievertakking voor uw twee main App Service-apps instellen main op (zie Implementatievertakking main Stel in Cloud Shell DEPLOYMENT_BRANCH app-instelling in met de opdracht az webapp config appsettings set .

    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. Voer in het lokale terminalvenster de volgende Git-opdrachten uit om de implementatie in de back-end-app uit te voeren. Vervang deploymentLocalGitUrl-of-back-end-app > door de URL van de externe Git-app die u hebt opgeslagen in > Wanneer u door Git Credential Manager om referenties wordt gevraagd, geeft u de referenties voor implementatie op en niet de referenties die u gebruikt om u aan te melden bij de Azure-portal.

    git remote add backend <deploymentLocalGitUrl-of-back-end-app>
    git push backend main
    
  3. Voer in het lokale terminalvenster de volgende Git-opdrachten uit om dezelfde code in de front-end-app te implementeren. Vervang deploymentLocalGitUrl-of-front-end-app > door de URL van de externe Git-app die u hebt opgeslagen in >

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

Naar de apps bladeren

Ga in een browser naar de volgende URL's om de twee apps in werking te zien.

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.

Notitie

Als de app opnieuw wordt gestart, hebt u wellicht gezien dat nieuwe gegevens zijn gewist. Dit gedrag is inherent aan het ontwerp omdat de ASP.NET Core-voorbeeld-app gebruikmaakt van een database in het geheugen.

Back-end-API aanroepen vanuit front-end

In deze stap legt u voor de servercode van de front-end-app vast dat toegang tot de back-end-API mogelijk is. Later schakelt u geverifieerde toegang in vanaf de front-end tot de back-end.

Front-end-code wijzigen

  1. Open Controllers/TodoController.cs in de lokale opslagplaats. Voeg aan het begin van de klasse de volgende regels toe en TodoController vervang TodoController door de naam van uw back-end-app:

    private static readonly HttpClient _client = new HttpClient();
    private static readonly string _remoteUrl = "https://<back-end-app-name>.azurewebsites.net";
    
  2. Zoek de methode die is voorzien van [HttpGet], en vervang de code binnen de accolades door:

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

    In de eerste regel wordt een GET /api/Todo-aanroep naar de back-end-API-app uitgevoerd.

  3. Zoek vervolgens de methode die is voorzien van [HttpGet("{id}")], en vervang de code binnen de accolades door:

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

    In de eerste regel wordt een GET /api/Todo/{id}-aanroep naar de back-end-API-app uitgevoerd.

  4. Zoek vervolgens de methode die is voorzien van [HttpPost], en vervang de code binnen de accolades door:

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

    In de eerste regel wordt een POST /api/Todo-aanroep naar de back-end-API-app uitgevoerd.

  5. Zoek vervolgens de methode die is voorzien van [HttpPut("{id}")], en vervang de code binnen de accolades door:

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

    In de eerste regel wordt een PUT /api/Todo/{id}-aanroep naar de back-end-API-app uitgevoerd.

  6. Zoek vervolgens de methode die is voorzien van [HttpDelete("{id}")], en vervang de code binnen de accolades door:

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

    In de eerste regel wordt een DELETE /api/Todo/{id}-aanroep naar de back-end-API-app uitgevoerd.

  7. Sla al uw wijzigingen op. Implementeer via het lokale terminalvenster de wijzigingen aan de front-end-app met de volgende Git-opdrachten:

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

Wijzigingen controleren

  1. Ga naar http://<front-end-app-name>.azurewebsites.net en voeg enkele items toe, bijvoorbeeld from front end 1 en from front end 2.

  2. Ga naar http://<back-end-app-name>.azurewebsites.net om de items te zien die aan de front-end-app zijn toegevoegd. Voeg nu ook een paar items toe, zoals from back end 1 en from back end 2, en vernieuw de front-end-app om de doorgevoerde wijzigingen te zien.

    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.

Verificatie configureren

In deze stap schakelt u verificatie en autorisatie voor de twee apps in. U configureert ook de front-end-app om een toegangstoken te genereren dat u kunt gebruiken om geverifieerde aanroepen uit te voeren naar de back-end-app.

U gebruikt Azure Active Directory als id-provider. Zie Verificatie van Azure Active Directory configureren voor de App Services-toepassing voor meer informatie.

Verificatie en autorisatie voor de back-end-app inschakelen

  1. Selecteer in het menu van de Azure-portal de optie Resourcegroepen of zoek ernaar en selecteer Resourcegroepen vanaf een willekeurige pagina.

  2. Zoek in Resourcegroepen uw resourcegroep en selecteer deze. Selecteer in Overzicht de beheerpagina van de back-end-app.

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

  3. Selecteer verificatie in het linkermenu van de back-end-app en klik vervolgens op Id-provider toevoegen.

  4. Selecteer op de pagina Een id-provider toevoegen de optie Microsoft als id-provider om Microsoft- en Azure AD-identiteiten aan te melden.

  5. Accepteer de standaardinstellingen en klik op Toevoegen.

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

  6. De pagina Verificatie wordt geopend. Kopieer de Client-id van de Azure AD-toepassing in een kladblok. U hebt deze waarde later nog nodig.

    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.

Als u hier stopt, hebt u een zelfstandige app die al wordt beveiligd met verificatie en autorisatie van App Service. In de overige secties ziet u hoe u een oplossing met meerdere apps kunt beveiligen door de geverifieerde gebruiker van de front-end naar de back-end te ‘stromen’.

Verificatie en autorisatie voor de front-end-app inschakelen

Volg dezelfde stappen voor de front-end-app, maar sla de laatste stap over. U hebt de client-id niet nodig voor de front-end-app. Blijf echter op de pagina Verificatie voor de front-end-app, omdat u deze in de volgende stap gaat gebruiken.

Ga, als u wilt, naar http://<front-end-app-name>.azurewebsites.net. U wordt nu doorgestuurd naar een beveiligde aanmeldingspagina. Nadat u zich hebt aangemeld, hebt u nog steeds geen toegang tot de gegevens van de back-end-app, omdat voor de back-end-app nu Azure Active Directory-aanmelding vanuit de front-end-app is vereist. U moet drie dingen doen:

  • De front-end toegang geven tot de back-end
  • App Service configureren zodat een bruikbaar token wordt geretourneerd
  • De token in de code gebruiken

Tip

Als u tegen fouten aanloopt en de instellingen voor verificatie en autorisatie opnieuw configureert, kunnen de tokens in het tokenarchief mogelijk niet met de nieuwe instellingen opnieuw worden gegenereerd. Als u er zeker van wilt zijn dat de tokens opnieuw worden gegenereerd, dient u zich af te melden en vervolgens opnieuw aan te melden. U kunt dit doen door de browser in de privémodus te zetten en de browser vervolgens te sluiten en opnieuw in de privémodus te openen nadat u de instellingen in de apps hebt gewijzigd.

Front-end-app toegang verlenen tot de back-end-app

Nu u voor beide apps verificatie en autorisatie hebt ingeschakeld, worden beide door een AD-toepassing ondersteund. In deze stap geeft u de front-end-app namens de gebruiker machtigingen voor toegang tot de back-end-app. (Technisch gesproken geeft u de AD-toepassing van de front-end-app namens de gebruiker machtigingen voor toegang tot de AD-toepassing van de back-end-app.)

  1. Selecteer op de pagina Verificatie voor de front-end-app de naam van uw front-end-app onder Id-provider. Deze app-registratie is automatisch voor u gegenereerd. Selecteer API-machtigingen in het menu links.

  2. Selecteer Een machtiging toevoegenen selecteer vervolgens Mijn API's back-end-app-name.

  3. Selecteer op de pagina API-machtigingen aanvragen voor de back-end-app de optie Gedelegeerde machtigingen en user_impersonation. Selecteer vervolgens Machtigingen toevoegen.

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

App Service configureren zodat een bruikbaar toegangstoken wordt geretourneerd

De front-end-app beschikt nu over de vereiste machtigingen voor toegang tot de back-end-app als de aangemelde gebruiker. In deze stap configureert u App Service-verificatie en -autorisatie zodat u een bruikbaar toegangstoken hebt voor toegang tot de back-end. Voor deze stap hebt u de client-id van de back-end nodig die u hebt gekopieerd bij Verificatie en autorisatie voor de back-end-app inschakelen.

Voer in Cloud Shell volgende opdrachten uit op de front-end-app om de parameter toe te scope voegen aan de verificatie-instelling identityProviders.azureActiveDirectory.login.loginParameters . Vervang front-end-app-name > en >

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"

Met de opdrachten wordt effectief een loginParameters eigenschap toegevoegd met aanvullende aangepaste scopes. Hier volgt een uitleg van de aangevraagde scopes:

Tip

  • Als u het bereik in de Azure Portal wilt weergeven, gaat u naar de pagina Verificatie voor de api://<back-end-client-id>/user_impersonation back-end-app, klikt u op de koppeling onder api://<back-end-client-id>/user_impersonation Id-provider en klikt u vervolgens op Een API beschikbaar maken in het menu links.
  • Als u in plaats daarvan de vereiste scopes wilt configureren met behulp van een webinterface, bekijkt u de Microsoft-stappen in Auth-tokens vernieuwen.
  • Voor sommige scopes is toestemming van de beheerder of gebruiker vereist. Deze vereiste zorgt ervoor dat de pagina voor toestemmingsaanvraag wordt weergegeven wanneer een gebruiker zich in de browser bij de front-end-app meldt. Om deze toestemmingspagina te voorkomen, voegt u de app-registratie van de front-end toe als een geautoriseerde clienttoepassing op de pagina Een API beschikbaar maken door te klikken op Een clienttoepassing toevoegen en de client-id van de app-registratie van de front-end op te geven.

Notitie

Voor Linux-apps is er een tijdelijke vereiste voor het configureren van een versie-instelling voor de registratie van de back-end-app. Configureer Cloud Shell in de lijst met de volgende opdrachten. Zorg ervoor dat u back-end-client-id vervangt door > de client-id van uw 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}}" 

Uw apps zijn nu geconfigureerd. De front-end is nu gereed voor toegang tot de back-end met het juiste toegangstoken.

Zie Toegangstokens van id-providers vernieuwen voor informatie over het configureren van het toegangstoken voor andere providers.

API veilig aanroepen vanuit servercode

In deze stap activeert u de eerder gewijzigde servercode, zodat u geverifieerde aanroepen naar de back-end-API kunt uitvoeren.

De front-end-app heeft nu de vereiste machtiging en voegt tevens de client-id van de back-end-app toe aan de aanmeldingsparameters. Op die manier kan een toegangstoken voor verificatie van de back-end-app verkregen worden. App Service token levert aan uw servercode door een header in te voeren op elke geverifieerde aanvraag (zie Tokens ophalen X-MS-TOKEN-AAD-ACCESS-TOKENX-MS-TOKEN-AAD-ACCESS-TOKEN

Notitie

Deze headers worden voor alle ondersteunde talen geïnjecteerd. U kunt ze openen met het standaardpatroon voor elke betreffende taal.

  1. Open opnieuw Controllers/TodoController.cs in de lokale opslagplaats. Voeg onder de TodoController(TodoContext context)-constructor de volgende code toe:

    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"]);
    }
    

    Met deze code wordt de standaard-HTTP-header Authorization: Bearer <access-token> aan alle externe API-aanroepen toegevoegd. In de ASP.NET Core-pijplijn voor de uitvoering van de aanvraag wordt OnActionExecuting vlak voor de desbetreffende actie uitgevoerd, zodat nu elke uitgaande API-aanroep over het toegangstoken beschikt.

  2. Sla al uw wijzigingen op. Implementeer via het lokale terminalvenster de wijzigingen aan de front-end-app met de volgende Git-opdrachten:

    git add .
    git commit -m "add authorization header for server code"
    git push frontend main
    
  3. Meld u opnieuw aan bij https://<front-end-app-name>.azurewebsites.net. Klik op de pagina over de gebruiksovereenkomst voor gebruikersgegevens op Accepteren.

    U moet nu net als eerder gegevens uit de back-end-app kunnen maken, lezen, bijwerken en verwijderen. Het enige verschil is dat beide apps nu worden beveiligd door App Service-verificatie en -autorisatie, waaronder de aanroepen tussen services.

Gefeliciteerd! De servercode heeft nu toegang tot de gegevens van de back-end namens de geverifieerde gebruiker.

API veilig vanuit browsercode aanroepen

In deze stap legt u vast dat de Angular.js-app van de front-end naar de back-end-API verwijst. Op die manier leert u hoe u het toegangstoken kunt ophalen en er API-aanroepen naar de back-end-app mee kunt uitvoeren.

Hoewel de servercode toegang heeft tot aanvraagheaders, heeft clientcode toegang tot om dezelfde toegangstokens op te halen GET /.auth/me (zie GET /.auth/me

Tip

In deze sectie worden de standaard-HTTP-methoden gebruikt om de veilige HTTP-aanroepen te demonstreren. U kunt echter Microsoft Authentication Library voor JavaScript gebruiken om het Angular.js-toepassingspatroon te vereenvoudigen.

CORS configureren

Schakel in Cloud Shell CORS in voor de URL van de client met de opdracht az webapp cors add. Vervang de tijdelijke aanduidingen > back-end-app-name en >

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

Deze stap heeft geen betrekking op verificatie en autorisatie. U hebt deze echter nodig zodat de browser API-aanroepen tussen domeinen vanaf de Angular.js-app toestaat. Zie CORS-functionaliteit toevoegen voor meer informatie.

Angular.js-app naar back-end-API laten verwijzen

  1. Open wwwroot/index.html in de lokale opslagplaats.

  2. Stel in regel 51 de variabele apiEndpoint in op de HTTPS URL van de back-end-app (https://<back-end-app-name>.azurewebsites.net). Vervang back-end-app-name > door de naam van uw app in App Service.

  3. Open wwwroot/app/scripts/todoListSvc.js in de lokale opslagplaats en kijk of is voorbereid op alle API-aanroepen. De Angular.js-app roept nu de back-end-API's aan.

Toegangstoken toevoegen aan API-aanroepen

  1. Voeg in wwwroot/app/scripts/todoListSvc.jsboven de lijst met API-aanroepen (boven de regel ) de volgende functie toe aan de lijst:

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

    Deze functie wordt aangeroepen om de standaard-Authorization-header in te stellen met het toegangstoken. De functie wordt in de volgende stap aangeroepen.

  2. Open wwwroot/app/scripts/app.js in de lokale opslagplaats en zoek de volgende code:

    $routeProvider.when("/Home", {
        controller: "todoListCtrl",
        templateUrl: "/App/Views/TodoList.html",
    }).otherwise({ redirectTo: "/Home" });
    
  3. Vervang het hele codeblok door de volgende code:

    $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" });
    

    Door deze wijziging wordt de toewijzing resolve toegevoegd, waarmee /.auth/me wordt aangeroepen en het toegangstoken ingesteld. Hiermee wordt gegarandeerd dat u over het toegangstoken beschikt voordat de controller todoListCtrl wordt geïnstantieerd. Op die manier bevatten alle API-aanroepen van de controller het token.

Updates implementeren en tests uitvoeren

  1. Sla al uw wijzigingen op. Implementeer via het lokale terminalvenster de wijzigingen aan de front-end-app met de volgende Git-opdrachten:

    git add .
    git commit -m "add authorization header for Angular"
    git push frontend main
    
  2. Ga opnieuw naar https://<front-end-app-name>.azurewebsites.net. U moet nu rechtstreeks in de Angular.js-app gegevens in de back-end kunnen maken, lezen, bijwerken en verwijderen.

Gefeliciteerd! De clientcode heeft nu toegang tot de gegevens van de back-end namens de geverifieerde gebruiker.

Wanneer de toegangstokens verlopen

Uw toegangstoken verloopt na bepaalde tijd. Voor meer informatie over het vernieuwen van uw toegangstokens zonder dat gebruikers zich opnieuw moeten verifiëren bij uw app raadpleegt u Toegangstokens van id-providers vernieuwen.

Resources opschonen

In de voorgaande stappen hebt u Azure-resources in een resourcegroep gemaakt. Als u deze resources niet meer nodig denkt te hebben, verwijdert u de resourcegroep door de volgende opdracht in Cloud Shell uit te voeren:

az group delete --name myAuthResourceGroup

Het kan een minuut duren voordat deze opdracht is uitgevoerd.

Volgende stappen

Wat u hebt geleerd:

  • Ingebouwde verificatie en autorisatie inschakelen
  • Apps beveiligen tegen niet-geverifieerde aanvragen
  • Azure Active Directory gebruiken als id-provider
  • Externe apps openen namens de aangemelde gebruiker
  • Aanroepen tussen services beveiligen met tokenverificatie
  • Toegangstokens gebruiken vanuit servercode
  • Toegangstokens gebruiken vanuit clientcode (browser)

Ga door naar de volgende zelfstudie om te leren hoe u een aangepaste DNS-naam aan uw app kunt toewijzen.