Självstudie: Autentisera och auktorisera användare från slutpunkt till slutpunkt i Azure App Service

Azure App Service ger en mycket skalbar webbvärdtjänst med självkorrigering. I App Service finns dessutom funktioner för användarautentisering och auktorisering. I den här kursen visar vi hur du skyddar appar med App Service-autentisering och auktorisering. Den använder en ASP.NET Core app med en Angular.js klientdel som exempel. App Service-autentisering och autentisering stöder alla språkkörningar. Du kan lära dig hur du använder det med det språk du föredrar genom att följa självstudiekursen.

Azure App Service tillhandahåller en mycket skalbar webbvärdtjänst med självkorrigering med hjälp av Linux-operativsystemet. I App Service finns dessutom funktioner för användarautentisering och auktorisering. I den här kursen visar vi hur du skyddar appar med App Service-autentisering och auktorisering. Den använder en ASP.NET Core app med en Angular.js klientdel som exempel. App Service-autentisering och autentisering stöder alla språkkörningar. Du kan lära dig hur du använder det med det språk du föredrar genom att följa självstudiekursen.

Enkel autentisering och auktorisering

Här ser du också hur du skyddar en app med flera nivåer genom att öppna ett skyddat server-API åt den autentiserade användaren, från både serverkoden och webbläsarkoden.

Avancerad autentisering och auktorisering

Det här är endast några av de möjliga scenarierna för autentisering och auktorisering i App Service.

Här är en mer utförlig lista över saker du lär dig under självstudiekursen:

  • Aktivera inbyggd autentisering och auktorisering
  • Skydda appar mot oautentiserade begäranden
  • Använda Azure Active Directory som identitetsleverantör
  • Få åtkomst till en fjärrapp å den inloggade användarens vägnar
  • Säkra tjänst-till-tjänst-anrop med tokenautentisering
  • Använda åtkomsttoken från serverkod
  • Använd åtkomsttoken från klientkod (webbläsare)

Du kan följa stegen i den här självstudien i macOS, Linux och Windows.

Om du inte har en Azure-prenumeration skapar du ett kostnadsfritt Azure-konto innan du börjar.

Förutsättningar

För att slutföra den här kursen behöver du:

Du kan använda antingen Azure Cloud Shell eller ett lokalt Azure CLI.

Skapa en lokal .NET Core-app

I det här steget konfigurerar du det lokala .NET Core-projektet. Du kan använda samma projekt för att distribuera en API-app på serversidan och en webbapp på klientsidan.

Klona och kör exempelprogrammet

  1. Kör följande kommandon för att klona exempellagringsplatsen och köra den.

    git clone https://github.com/Azure-Samples/dotnet-core-api
    cd dotnet-core-api
    dotnet run
    
  2. Öppna http://localhost:5000 och prova att lägga till, redigera och ta bort att göra-objekt.

    ASP.NET Core-API som körs lokalt

  3. Tryck i terminalen för att stoppa ASP.NET CoreCtrl+C.

  4. Kontrollera att standardgrenen är main.

    git branch -m main
    

    Tips

    Ändringen av grennamn krävs inte av App Service. Men eftersom många lagringsplatser ändrar sin standardgren till mainvisar den här självstudien också hur du distribuerar en lagringsplats från main. Mer information finns i Ändra distributionsgren.

Distribuera appar till Azure

I det här steget distribuerar du projektet till två App Service-appar. Den ena är en klientdelsapp och den andra är en serverdelsapp.

Konfigurera en distributionsanvändare

FTP och lokal Git kan distribuera till en Azure-webbapp med hjälp av en distributionsanvändare. När du har konfigurerat distributionsanvändaren kan du använda den för alla dina Azure-distributioner. Ditt användarnamn och lösenord för distribution på kontonivå skiljer sig från dina autentiseringsuppgifter för Azure-prenumerationen.

Om du vill konfigurera distributionsanvändaren kör du kommandot az webapp deployment user set i Azure Cloud Shell. Ersätt <användarnamn> och <lösenord> med ett användarnamn och lösenord för distributionsanvändaren.

  • Användarnamnet måste vara unikt i Azure, och för lokala Git-push-meddelanden får det inte innehålla @-symbolen.
  • Lösenordet måste vara minst åtta tecken långt, med två av följande tre element: bokstäver, siffror och symboler.
az webapp deployment user set --user-name <username> --password <password>

JSON-utdata visar lösenordet som null. Om du ser felet 'Conflict'. Details: 409 ska du byta användarnamn. Om du ser felet 'Bad Request'. Details: 400 ska du använda ett starkare lösenord.

Registrera ditt användarnamn och lösenord som ska användas för att distribuera dina webbappar.

Skapa Azure-resurser

I Cloud Shell kör du följande kommandon för att skapa två Windows-webbappar. Ersätt <front-end-app-name> och <back-end-app-name> med två globalt unika appnamn (giltiga tecken är a-z, 0-9och -). Mer information om varje kommando finns i Värd för ett RESTful-API med CORS i 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

Kör följande kommandon i Cloud Shell för att skapa två webbappar. Ersätt <front-end-app-name> och <back-end-app-name> med två globalt unika appnamn (giltiga tecken är a-z, 0-9och -). Mer information om varje kommando finns i Skapa en .NET Core-app i Azure App Service.

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

Anteckning

Spara webbadresserna till Git-fjärrobjekten för klientdels- och serverdelsapparna. De visas i utdata från az webapp create.

Skicka till Azure från Git

  1. Eftersom du distribuerar grenen main måste du ange standarddistributionsgrenen för dina två App Service appar till main (se Ändra distributionsgren). I Cloud Shell anger du appinställningen DEPLOYMENT_BRANCHaz webapp config appsettings set med kommandot .

    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. Åter i det lokala terminalfönstret kör du följande Git-kommandon för att distribuera till serverdelsappen. Ersätt <deploymentLocalGitUrl-of-back-end-app> med URL:en för git-fjärrens som du sparade från Skapa Azure-resurser. När du uppmanas att ange autentiseringsuppgifter av Git Credential Manager kontrollerar du att du anger dina distributionsuppgifter, inte de autentiseringsuppgifter som du använder för att logga in på Azure Portal.

    git remote add backend <deploymentLocalGitUrl-of-back-end-app>
    git push backend main
    
  3. Kör följande Git-kommandon i det lokala terminalfönstret för att distribuera samma kod till klientdelsappen. Ersätt <deploymentLocalGitUrl-of-front-end-app> med URL:en för Den Git-fjärr som du sparade från Skapa Azure-resurser.

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

Bläddra till apparna

Navigera till följande URL:er i en webbläsare och se hur de två apparna fungerar.

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

Skärmbild av ett Azure App Service REST API-exempel i ett webbläsarfönster, som visar en Att göra-lista-app.

Anteckning

Om appen startar om noterade du kanske att nya data har tagits bort. Det här är avsiktligt eftersom ASP.NET Core-exempelappen använder en minnesintern databas.

Anropa serverdels-API från klientsidan

I det här steget använder du serverkoden för klientdelsappen för att komma åt serverdels-API:t. Du aktiverar senare autentiserad åtkomst från klientdelen till serverdelen.

Ändra klientdelskod

  1. Öppna Controllers/TodoController.cs på den lokala lagringsplatsen. I början av TodoController klassen lägger du till följande rader och ersätter <serverdelsappens namn> med namnet på serverdelsappen:

    private static readonly HttpClient _client = new HttpClient();
    private static readonly string _remoteUrl = "https://<back-end-app-name>.azurewebsites.net";
    
  2. Hitta den metod som är dekorerad med [HttpGet] och ersätt koden inuti klammerparenteserna med:

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

    Den första raden gör ett GET /api/Todo-anrop till serverdels-API-appen.

  3. Leta sedan upp metoden som är dekorerad med [HttpGet("{id}")] och ersätt koden i klammerparenteserna med:

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

    Den första raden gör ett GET /api/Todo/{id}-anrop till serverdels-API-appen.

  4. Leta sedan upp metoden som är dekorerad med [HttpPost] och ersätt koden i klammerparenteserna med:

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

    Den första raden gör ett POST /api/Todo-anrop till serverdels-API-appen.

  5. Leta sedan upp metoden som är dekorerad med [HttpPut("{id}")] och ersätt koden i klammerparenteserna med:

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

    Den första raden gör ett PUT /api/Todo/{id}-anrop till serverdels-API-appen.

  6. Leta sedan upp metoden som är dekorerad med [HttpDelete("{id}")] och ersätt koden i klammerparenteserna med:

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

    Den första raden gör ett DELETE /api/Todo/{id}-anrop till serverdels-API-appen.

  7. Spara alla ändringar. I det lokala terminalfönstret distribuerar du ändringarna till klientdelsappen med följande Git-kommandon:

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

Kontrollera ändringarna

  1. Öppna http://<front-end-app-name>.azurewebsites.net och lägg till några objekt, exempelvis from front end 1 och from front end 2.

  2. Navigera till http://<back-end-app-name>.azurewebsites.net för att visa de objekt som lades till från klientdelsappen. Lägg även till några objekt, som from back end 1 och from back end 2, och uppdatera sedan klientdelsappen för att se om ändringarna visas.

    Skärmbild av ett Azure App Service REST API-exempel i ett webbläsarfönster, som visar en Att göra-lista-app med objekt som lagts till från klientdelsappen.

Konfigurera autentisering

I det här steget aktiverar du autentisering och auktorisering för två appar. Du kan också konfigurera klientdelsappen och generera en åtkomsttoken som du kan använda till att göra autentiserade anrop till serverdelsappen.

Du använder Azure Active Directory som identitetsleverantör. Mer information finns i Konfigurera Azure Active Directory-autentisering för App Services-appen.

Aktivera autentisering och auktorisering för serverdelsapp

  1. menyn Azure Portal väljer du Resursgrupper eller söker efter och väljer Resursgrupper på valfri sida.

  2. Leta reda på och välj din resursgrupp i Resursgrupper. I Översikt väljer du serverdelsappens hanteringssida.

    Skärmbild av fönstret Resursgrupper som visar översikten för en exempelresursgrupp och en serverdelsapps hanteringssida markerad.

  3. I serverdelsappens vänstra meny väljer du Autentisering och klickar sedan på Lägg till identitetsprovider.

  4. På sidan Lägg till en identitetsprovider väljer du Microsoft som identitetsprovider för att logga in Microsoft och Azure AD identiteter.

  5. Acceptera standardinställningarna och klicka på Lägg till.

    Skärmbild av serverdelsappens vänstra meny med autentisering/auktorisering markerad och inställningar som valts på den högra menyn.

  6. Sidan Autentisering öppnas. Kopiera klient-ID:t för Azure AD-programmet till ett anteckningsblock. Du behöver det här värdet senare.

    Skärmbild av fönstret Azure Active Directory-inställningar som visar Azure AD-appen och fönstret Azure AD program som visar klient-ID:t som ska kopieras.

Om du slutar här har du en fristående app som redan skyddas av App Service autentisering och auktorisering. De återstående avsnitten visar hur du skyddar en lösning med flera appar genom att "flöda" den autentiserade användaren från klientdelen till serverdelen.

Aktivera autentisering och auktorisering för klientappen

Följ samma steg för klientdelsappen, men hoppa över det sista steget. Du behöver inte klient-ID:t för klientdelsappen. Stanna dock kvar på sidan Autentisering för klientdelsappen eftersom du kommer att använda den i nästa steg.

Om du vill kan du navigera till http://<front-end-app-name>.azurewebsites.net. Du bör nu dirigeras till en säker inloggningssida. När du har loggat in kan du fortfarande inte komma åt data från serverdelsappen eftersom serverdelsappen nu kräver Azure Active Directory-inloggning från klientdelsappen. Du måste göra tre saker:

  • Ge klientsidan åtkomst till serversidan
  • Konfigurera App Service för att returnera en användbar token
  • Använda token i koden

Tips

Om du stöter på fel och konfigurerar om inställningarna för autentisering/auktorisering för appen kan det hända att tokenenheterna i tokenarkivet inte skapas om från de nya inställningarna. För att se till att dina token skapas måste du logga ut och sedan logga in i appen igen. Ett enkelt sätt att göra det är att använda webbläsaren i privat läge. Stäng webbläsaren och öppna den sedan i privat läge igen när du har ändrat inställningarna i dina appar.

Ge klientdelsappen åtkomst till serversidan

Nu när du har aktiverat autentisering och auktorisering för båda dina appar backas var och en av dem upp av ett AD-program. I det här steget kan ge du klientdelsappen åtkomstbehörighet till serverdelsappen å användarens vägnar. (Tekniskt sett ger du AD-programmet för klientdelsappen behörighet att komma åt AD-programmet för serverdelen å användarens vägnar.)

  1. På sidan Autentisering för klientdelsappen väljer du ditt klientdelsappnamn under Identitetsprovider. Den här appregistreringen genererades automatiskt åt dig. Välj API-behörigheter på den vänstra menyn.

  2. Välj Lägg till en behörighet och välj sedan Mina API:er><back-end-app-name>.

  3. På sidan Begär API-behörigheter för serverdelsappen väljer du Delegerade behörigheter och user_impersonation och väljer sedan Lägg till behörigheter.

    Skärmbild av sidan Förfrågnings-API-behörigheter som visar delegerade behörigheter, user_impersonation och knappen Lägg till behörighet har valts.

Konfigurera App Service för att returnera en användbar åtkomsttoken

Klientdelsappen har nu de behörigheter som krävs för att komma åt serverdelsappen som den inloggade användaren. I det här steget konfigurerar du autentisering och auktorisering för App Service, så att du får en användbar åtkomsttoken för att komma åt serverdelen. För det här steget behöver du serverdelens klient-ID, som du kopierade från Aktivera autentisering och auktorisering för serverdelsappen.

I Cloud Shell kör du följande kommandon i klientdelsappen för att lägga till parametern scope i autentiseringsinställningen identityProviders.azureActiveDirectory.login.loginParameters. Ersätt <klientdelens appnamn> och <serverdelsklient-ID>.

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"

Kommandona lägger effektivt till en loginParameters egenskap med ytterligare anpassade omfång. Här är en förklaring av de begärda omfången:

  • openid, profileoch email begärs redan av App Service som standard. Mer information finns i OpenID Connect-omfång.
  • api://<back-end-client-id>/user_impersonation är ett exponerat API i din registrering av serverdelsappar. Det är omfånget som ger dig en JWT-token som innehåller serverdelsappen som en token-målgrupp.
  • offline_access ingår här för enkelhetens skull (om du vill uppdatera token).

Tips

  • Om du vill visa omfånget api://<back-end-client-id>/user_impersonation i Azure Portal går du till sidan Autentisering för serverdelsappen, klickar på länken under Identitetsprovider och klickar sedan på Exponera ett API på den vänstra menyn.
  • Information om hur du konfigurerar de nödvändiga omfången med hjälp av ett webbgränssnitt finns i Microsoft-stegen i Uppdatera autentiseringstoken.
  • Vissa omfång kräver administratörs- eller användarmedgivande. Det här kravet gör att sidan med medgivandebegäran visas när en användare loggar in på klientdelsappen i webbläsaren. Undvik den här medgivandesidan genom att lägga till klientdelens appregistrering som ett auktoriserat klientprogram på sidan Exponera ett API genom att klicka på Lägg till ett klientprogram och ange klient-ID för klientdelens appregistrering.

Anteckning

För Linux-appar finns det ett tillfälligt krav på att konfigurera en versionsinställning för registrering av serverdelsappen. I Cloud Shell konfigurerar du den med följande kommandon. Se till att ersätta <serverdelsklient-ID> med serverdelens klient-ID.

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

Nu har apparna konfigurerats. Klientdelen är nu redo att komma åt serverdelen med en åtkomsttoken.

Information om hur du konfigurerar åtkomsttoken för andra leverantörer finns i Uppdatera identitetsprovidertoken.

Anropa API på säkert sätt från serverkod

I det här steget aktiverar du din tidigare ändrade serverkod så att du kan göra autentiserade anrop till serverdels-API:et.

Klientdelsappen har nu den behörighet som krävs och lägger även till serverdelens klient-ID i inloggningsparametrarna. Den kan därför få en åtkomsttoken för autentisering utan serverdelsappen. App Service tillhandahåller denna token i serverkoden genom att införa en X-MS-TOKEN-AAD-ACCESS-TOKEN-rubrik för varje autentiserad begäran (se Hämta token i appkod).

Anteckning

Dessa rubriker införs för alla språk som stöds. Du har åtkomst till dem med hjälp av standardmönstret för respektive språk.

  1. Öppna Controllers/TodoController.cs igen i den lokala databasen. Under konstruktorn TodoController(TodoContext context) lägger du till följande kod:

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

    Den här koden lägger till den vanliga HTTP-rubrikenAuthorization: Bearer <access-token> till alla fjärranslutna API-anrop. I pipelinen ASP.NET Core MVC-begärandekörning OnActionExecuting körs precis innan respektive åtgärd gör det, så att vart och ett av ditt utgående API-anrop nu visar åtkomsttoken.

  2. Spara alla ändringar. I det lokala terminalfönstret distribuerar du ändringarna till klientdelsappen med följande Git-kommandon:

    git add .
    git commit -m "add authorization header for server code"
    git push frontend main
    
  3. Logga in på https://<front-end-app-name>.azurewebsites.net igen. På sidan med dataanvändningsavtalet klickar du på acceptera.

    Du bör nu kunna skapa, läsa, uppdatera och ta bort data från serverdelsappen, precis som innan. Den enda skillnaden är att båda apparna är nu skyddade med App Service-autentisering och -auktorisering, inklusive tjänst-till-tjänst-anrop.

Grattis! Serverkoden har nu åtkomst till serverdelsdata å den autentiserade användarens vägnar.

Anropa API på ett säkert sätt från webbläsarkoden

I det här steget pekar du Angular.js-appen för klientdelen till API:et för serverdelen. På så sätt får du veta hur du kan hämta åtkomsttoken och göra API-anrop till serverdelsappen med den.

Medan serverkoden har åtkomst till begäranderubriker kan klientkoden komma åt GET /.auth/me för att få samma åtkomsttoken (se Hämta token i appkod).

Tips

Det här avsnittet använder vi standard-HTTP-metoder för att demonstrera det säkra HTTP-anropet. Du kan dock använda Microsoft Authentication Library för JavaScript för att förenkla Angular.js programmönstret.

Konfigurera CORS

I Cloud Shell aktiverar du CORS till din klient-URL med kommandot az webapp cors add. <Ersätt platshållarna backend-app-name> och <front-end-app-name>.

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

Det här steget är inte kopplat till autentisering och auktorisering. Du behöver det dock för att webbläsaren ska tillåta API-anrop från flera domäner från Angular.js-appen. Mer information finns i Lägga till CORS-funktioner.

Peka Angular.js-app till serverdels-API

  1. Öppna wwwroot/index.html på den lokala lagringsplatsen.

  2. I rad 51 anger du variabeln apiEndpoint till HTTPS-URL:en för serverdelsappen (https://<back-end-app-name>.azurewebsites.net). Ersätt <serverdelsappens namn> med ditt appnamn i App Service.

  3. På den lokala lagringsplatsen öppnar du wwwroot/app/scripts/todoListSvc.js och ser till att apiEndpoint är tillagt för alla API-anrop. Nu anropar Angular.js-appen serverdels-API:erna.

Lägga till åtkomsttoken till API-anrop

  1. Öppna wwwroot/app/scripts/todoListSvc.js. Ovanför listan med API-anrop (ovanför raden getItems : function(){), lägger du till följande funktion i listan:

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

    Den här funktionen anropas för att ange standardrubriken Authorization med åtkomsttoken. Du anropar den i nästa steg.

  2. På den lokala lagringsplatsen öppnar du wwwroot/app/scripts/app.js och hittar följande kod:

    $routeProvider.when("/Home", {
        controller: "todoListCtrl",
        templateUrl: "/App/Views/TodoList.html",
    }).otherwise({ redirectTo: "/Home" });
    
  3. Ersätt hela kodblocket med följande kod:

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

    Den nya ändringen lägger till resolve mappningen som anropar/.auth/me och anger åtkomsttoken. Det innebär att du med säkerhet har åtkomsttoken innan kontrollanten todoListCtrl initieras. På så sätt omfattar alla API-anrop av kontrollanten token.

Distribuera uppdateringar och testa

  1. Spara alla ändringar. I det lokala terminalfönstret distribuerar du ändringarna till klientdelsappen med följande Git-kommandon:

    git add .
    git commit -m "add authorization header for Angular"
    git push frontend main
    
  2. Navigera till https://<front-end-app-name>.azurewebsites.net igen. Du bör nu kunna skapa, läsa, uppdatera och ta bort data från serverdelsappen, direkt i Angular.js-appen.

Grattis! Klientkoden har nu åtkomst till serverdelsdata å den autentiserade användarens vägnar.

När åtkomsttoken upphör att gälla

Ditt åtkomsttoken upphör att gälla efter ett tag. Information om hur du uppdaterar dina åtkomsttoken utan att användarna måste autentiseras på nytt med din app finns på sidan om att uppdatera token för identitetsprovider.

Rensa resurser

I de föregående stegen skapade du Azure-resurser i en resursgrupp. Om du inte tror att du behöver dessa resurser i framtiden tar du bort resursgruppen genom att köra följande kommando i Cloud Shell:

az group delete --name myAuthResourceGroup

Det kan några minuter att köra kommandot.

Nästa steg

Vad du lärt dig:

  • Aktivera inbyggd autentisering och auktorisering
  • Skydda appar mot oautentiserade begäranden
  • Använda Azure Active Directory som identitetsleverantör
  • Få åtkomst till en fjärrapp å den inloggade användarens vägnar
  • Säkra tjänst-till-tjänst-anrop med tokenautentisering
  • Använda åtkomsttoken från serverkod
  • Använd åtkomsttoken från klientkod (webbläsare)

Gå vidare till nästa självstudie där du får lära dig att mappa ett anpassat DNS-namn till appen.