Dela via

Konfigurera din App Service- eller Azure Functions-app så att den använder Microsoft Entra-inloggning

Välj en annan autentiseringsprovider för att hoppa till den.

Den här artikeln visar hur du konfigurerar autentisering för Azure App Service eller Azure Functions så att din app loggar in användare med Microsofts identitetsplattform (Microsoft Entra) som autentiseringsprovider.

Välj en klient för ditt program och dess användare

Innan programmet kan logga in användare måste du registrera det i en klientorganisation för personal eller en extern klientorganisation. Om du gör din app tillgänglig för anställda eller företagsgäster registrerar du appen i en klientorganisation för arbetsplatsen. Om din app är avsedd för konsumenter och företagskunder registrerar du den i en extern klientorganisation.

  1. Logga in på Azure-portalen och gå till din app.

  2. Välj Inställningar> på appens vänstra meny och välj sedan Lägg till identitetsprovider.

  3. På sidan Lägg till en identitetsprovider väljer du Microsoft som identitetsprovidervärde för att logga in Microsoft- och Microsoft Entra-identiteter.

  4. Under Välj en klientorganisation för ditt program och dess användare väljer du antingen:

    • Personalkonfiguration (aktuell klientorganisation) för anställda och företagsgäster
    • Extern konfiguration för konsumenter och företagskunder

Välj appregistrering

App Service-autentiseringsfunktionen kan automatiskt skapa en appregistrering åt dig. Du kan också använda en registrering som du eller en katalogadministratör skapar separat.

Skapa en ny appregistrering automatiskt, såvida du inte behöver skapa en appregistrering separat. Du kan anpassa appregistreringen i administrationscentret för Microsoft Entra senare om du vill.

Följande situationer är de vanligaste fallen för att använda en befintlig appregistrering:

  • Ditt konto har inte behörighet att skapa appregistreringar i din Microsoft Entra-klientorganisation.
  • Du vill använda en appregistrering från en annan Microsoft Entra-klientorganisation än den som innehåller din app. Det är alltid så om du valde Extern konfiguration när du valde en klient.
  • Alternativet att skapa en ny registrering är inte tillgängligt för myndighetsmoln.

Alternativ 1: Skapa och använda en ny appregistrering

  1. Välj Skapa ny appregistrering.

  2. Som Namn anger du namnet på den nya appregistreringen.

  3. Välj värdet för kontotyp som stöds :

    • Nuvarande hyresgäst – enskild hyresgäst. Endast konton i denna organisationskatalog. Alla användar- och gästkonton i din katalog kan använda ditt program eller API. Använd det här alternativet om målgruppen är intern för din organisation.
    • Vilken som helst Microsoft Entra-katalog - Fleranvändare. Konton i någon organisationskatalog. Alla användare med ett arbets- eller skolkonto från Microsoft kan använda ditt program eller API. Dessa konton omfattar skolor och företag som använder Office 365. Använd det här alternativet om målgruppen är företags- eller utbildningskunder och för att aktivera multitenancy.
    • Alla Microsoft Entra-kataloger och personliga Microsoft-konton. Konton i en organisationskatalog och personliga Microsoft-konton (till exempel Skype eller Xbox). Alla användare med ett arbets- eller skolkonto eller ett personligt Microsoft-konto kan använda ditt program eller API. Den innehåller skolor och företag som använder Office 365, tillsammans med personliga konton som används för att logga in på tjänster som Xbox och Skype. Använd det här alternativet för att rikta dig mot så många Microsoft-identiteter som möjligt och aktivera multitenans.
    • Endast personliga Microsoft-konton. Personliga konton som används för att logga in på tjänster som Xbox och Skype. Använd det här alternativet för att rikta in dig på den bredaste uppsättningen Microsoft-identiteter.

Du kan ändra namnet på registreringen eller de kontotyper som stöds senare om du vill.

En klienthemlighet skapas som en platsanpassad applikationsinställning namngiven MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Om du vill hantera hemligheten i Azure Key Vault kan du uppdatera den inställningen senare för att använda Key Vault-referenser. Du kan också ändra detta till att använda en identitet i stället för en klienthemlighet. Stöd för att använda en identitet finns för närvarande i förhandsversion.

Alternativ 2: Använd en befintlig registrering som skapats separat

Om du vill använda en befintlig registrering väljer du antingen:

  • Välj en befintlig appregistrering i den här katalogen. Välj sedan en appregistrering i listrutan.

  • Ange information om en befintlig appregistrering. Ge sedan:

    • Program-ID (klient).

    • Klienthemlighet (rekommenderas). Ett hemligt värde som programmet använder för att bevisa sin identitet när det begär en token. Det här värdet sparas i appens konfiguration som en slot-sticky-programinställning med namnet MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Om klienthemligheten inte har angetts använder inloggningsåtgärder från tjänsten det implicita beviljandeflödet OAuth 2.0, vilket vi inte rekommenderar.

      Du kan också konfigurera programmet att använda en identitet i stället för en klienthemlighet. Stöd för att använda en identitet finns för närvarande i förhandsversion.

    • Utfärdar-URL. Den här URL:en har formen <authentication-endpoint>/<tenant-id>/v2.0. Ersätt <authentication-endpoint> med det autentiseringsslutpunktsvärde som är specifikt för molnmiljön. Till exempel skulle en arbetskraftsannonsering i global Azure använda https://sts.windows.net som sin autentiseringsendpunkt.

Om du behöver skapa en appregistrering manuellt i en klientorganisation för personal kan du läsa Registrera ett program med Microsofts identitetsplattform. När du går igenom registreringsprocessen bör du notera programmets (klient)-ID:t och klienthemlighetsvärdena.

Under registreringsprocessen går du till avsnittet Omdirigerings-URI:er och väljer Webb för plattform och anger en omdirigerings-URI. Ange till exempel https://contoso.azurewebsites.net/.auth/login/aad/callback.

Ändra nu appregistreringen:

  1. I den vänstra rutan väljer du Exponera ett API>Lägg till>Spara. Det här värdet identifierar programmet unikt när det används som en resurs, vilket gör att token som beviljar åtkomst begärs. Värdet är ett prefix för de områden du skapar.

    För en app med en enda hyresgäst kan du använda standardvärdet, som har formen api://<application-client-id>. Du kan också ange en mer läsbar URI som https://contoso.com/api, baserat på en av de verifierade domänerna för din klientorganisation. För en app med flera klientorganisationer måste du ange en anpassad URI. Mer information om godkända format för app-ID-URI:er finns i Rekommenderade säkerhetsmetoder för programegenskaper i Microsoft Entra-ID.

  2. Välj Lägg till ett omfång och sedan:

    1. I Omfångsnamn anger du user_impersonation.
    2. I Vem kan samtycka väljer du Administratörer och användare om du vill tillåta användare att samtycka till det här omfånget.
    3. Ange namnet på medgivandeomfånget. Ange en beskrivning som du vill att användarna ska se på medgivandesidan. Ange till exempel Åtkomstprogramnamn.
    4. Välj Lägg till definitionsområde.

  3. (Rekommenderas) Skapa ett klientpåstående för appen. Så här skapar du en klienthemlighet:

    1. I den vänstra rutan väljer du Certifikat och hemligheter>Klienthemligheter>Ny klienthemlighet.
    2. Ange en beskrivning och förfallodatum och välj sedan Lägg till.
    3. I fältet Värde kopierar du klienthemlighetsvärdet. När du har flyttat bort från den här sidan visas den inte igen.

    Du kan också konfigurera programmet att använda en identitet i stället för en klienthemlighet. Stöd för att använda en identitet finns för närvarande i förhandsversion.

  4. (Valfritt) Om du vill lägga till flera svars-URL:er väljer du Autentisering.

Konfigurera ytterligare kontroller

Ytterligare kontroller avgör vilka begäranden som tillåts komma åt ditt program. Du kan anpassa det här beteendet nu, eller så kan du justera inställningarna senare från huvudsidan Autentisering genom att välja Redigera bredvid Autentiseringsinställningar.

För klientapplikationskrav väljer du mellan att:

  • Tillåt endast begäranden från själva programmet.
  • Tillåt begäranden från specifika klientprogram.
  • Tillåt begäranden från alla program (rekommenderas inte).

För Identitetskrav väljer du om du vill:

  • Tillåt begäranden från valfri identitet.
  • Tillåt begäranden från specifika identiteter.

För Klientkrav väljer du om du vill:

  • Tillåt endast förfrågningar från utgivartenanten.
  • Tillåt begäranden från specifika klienter.
  • Använd standardbegränsningar baserat på utfärdaren.

Din app kan fortfarande behöva fatta andra auktoriseringsbeslut i kod. Mer information finns i Använda en inbyggd auktoriseringsprincip senare i den här artikeln.

Konfigurera autentiseringsinställningar

Autentiseringsinställningar avgör hur programmet svarar på oautentiserade begäranden. Standardvalen omdirigerar alla begäranden för att logga in med den nya providern. Du kan anpassa det här beteendet nu, eller så kan du justera inställningarna senare från huvudsidan Autentisering genom att välja Redigera bredvid Autentiseringsinställningar. Mer information finns i Autentiseringsflöde.

För Begränsa åtkomst avgör du om du vill:

  • Kräv autentisering.
  • Tillåt oautentiserad åtkomst.

För oautentiserade begäranden väljer du felalternativ:

  • HTTP 302 Found redirect: rekommenderas för webbplatser
  • HTTP 401 Unauthorized: rekommenderas för API:er
  • HTTP 403 Forbidden
  • HTTP 404 Not found

Välj Tokenarkiv (rekommenderas). Tokenarkivet samlar in, lagrar och uppdaterar token för ditt program. Du kan inaktivera det här beteendet senare om din app inte behöver token eller om du behöver optimera prestandan.

Lägg till identitetsprovidern

Om du har valt personalkonfiguration kan du välja Nästa: Behörigheter och lägga till alla Microsoft Graph-behörigheter som programmet behöver. Dessa behörigheter läggs till i appregistreringen, men du kan också ändra dem senare. Om du har valt extern konfiguration kan du lägga till Microsoft Graph-behörigheter senare.

  • Markera Lägga till.

Nu är du redo att använda Microsofts identitetsplattform för autentisering i din app. Providern visas på sidan Autentisering . Därifrån kan du redigera eller ta bort den här providerkonfigurationen.

Ett exempel på hur du konfigurerar Microsoft Entra-inloggning för en webbapp som har åtkomst till Azure Storage och Microsoft Graph finns i Lägga till appautentisering i webbappen.

Auktorisera begäranden

Som standard hanterar App Service-autentisering endast autentisering. Det avgör om uppringaren är den de säger att de är. Auktorisering, som avgör om anroparen ska ha åtkomst till en resurs, är ett steg längre än autentisering. Mer information finns i Grundläggande om auktorisering.

Din app kan fatta auktoriseringsbeslut i kod. App Service-autentisering tillhandahåller vissa inbyggda kontroller, vilket kan hjälpa, men de räcker kanske inte för att täcka appens auktoriseringsbehov. Följande avsnitt beskriver dessa funktioner.

Tips

Program med flera klienter bör verifiera utfärdaren och klient-ID:t för begäran som en del av den här processen för att kontrollera att värdena är tillåtna. När App Service-autentisering har konfigurerats för ett scenario med flera klienter verifieras inte vilken klientorganisation begäran kommer från. En app kan behöva begränsas till specifika klienter, baserat på om organisationen har registrerat sig för tjänsten (till exempel). Se Uppdatera koden för att hantera flera utfärdarvärden.

Utföra valideringar från programkod

När du utför auktoriseringskontroller i din appkod kan du använda anspråksinformationen som App Service-autentisering gör tillgänglig. Mer information finns i Åtkomst till användaranspråk i appkod.

Det inmatade x-ms-client-principal huvudet innehåller ett Base64-kodat JSON-objekt med anspråken som hävdas om anroparen. Som standard går dessa anspråk igenom en anspråksmappning, så anspråksnamnen kanske inte alltid matchar det du ser i token. Till exempel mappas anspråket tid till http://schemas.microsoft.com/identity/claims/tenantid i stället.

Du kan också arbeta direkt med det underliggande åtkomsttokenet från det injicerade x-ms-token-aad-access-token headern.

Använda en inbyggd auktoriseringsprincip

Den skapade appregistreringen autentiserar inkommande begäranden för din Microsoft Entra-klientorganisation. Som standard tillåter den också vem som helst i klientorganisationen att komma åt programmet. Den här metoden är bra för många program. Vissa program måste begränsa åtkomsten ytterligare genom att fatta auktoriseringsbeslut.

Programkoden är ofta den bästa platsen för att hantera anpassad auktoriseringslogik. För vanliga scenarier tillhandahåller Microsofts identitetsplattform dock inbyggda kontroller som du kan använda för att begränsa åtkomsten.

Det här avsnittet visar hur du aktiverar inbyggda kontroller med hjälp av Api:et för App Service-autentisering V2. För närvarande är det enda sättet att konfigurera dessa inbyggda kontroller med hjälp av Azure Resource Manager-mallar eller REST-API:et.

I API-objektet har Microsoft Entra-identitetsproviderns konfiguration ett validation avsnitt som kan innehålla ett defaultAuthorizationPolicy objekt, som visas i följande struktur:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Fastighet beskrivning
defaultAuthorizationPolicy En grupp med krav som måste uppfyllas för åtkomst till appen. Åtkomst beviljas baserat på en logisk AND över var och en av dess konfigurerade egenskaper. När allowedApplications och allowedPrincipals är båda konfigurerade måste den inkommande begäran uppfylla båda kraven för att godkännas.
allowedApplications En godkännandelista med strängapplikation klient-ID:n som representerar klientresursen som anropar appen. När den här egenskapen har konfigurerats som en icke-tom array, godkänns endast token som hämtas av ett program som anges i listan.

Den här principen utvärderar appid eller azp-anspråket av den inkommande token, som måste vara en tillträdes-token. Se anspråk på nyttolast.
allowedPrincipals En grupp kontroller som avgör om den huvudman som den inkommande begäran representerar kan få tillgång till appen. Tillfredsställelsen allowedPrincipals baseras på en logisk bedömning av dess konfigurerade egenskaper.
identities (under allowedPrincipals) En lista över strängobjekt-ID:er som representerar användare eller program som har åtkomst. När den här egenskapen har konfigurerats som en icke-tom matris, kan allowedPrincipals-kravet uppfyllas om användaren eller programmet som begäran representerar, anges i listan. Det finns en gräns på 500 tecken (totalt) i listan över identiteter.

Den här policyn utvärderar den inkommande tokenens oid-påstående. Se anspråk på nyttolast.

Du kan också konfigurera vissa kontroller via en programinställning, oavsett vilken API-version du använder. Du kan konfigurera programinställningen WEBSITE_AUTH_AAD_ALLOWED_TENANTS med en kommaavgränsad lista med upp till 10 klient-ID:t, aaaabbbb-0000-cccc-1111-dddd2222eeeetill exempel . Den här inställningen kan kräva att den inkommande token är från en av de angivna hyresgästerna, som anges av anspråket tid.

Du kan konfigurera programinställningen WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL till true eller 1, för att kräva att den inkommande token innehåller ett oid anspråk. Om du har konfigurerat allowedPrincipals.identitiesignoreras den här inställningen och behandlas som true eftersom anspråket kontrolleras mot den oid angivna listan med identiteter.

Begäranden som misslyckas med dessa inbyggda kontroller får ett HTTP-svar 403 Forbidden .

Använda en hanterad identitet i stället för en hemlighet (förhandsversion)

I stället för att konfigurera en klienthemlighet för din appregistrering kan du konfigurera ett program för att lita på en hanterad identitet (förhandsversion). Att använda en identitet i stället för en hemlighet innebär att du inte behöver hantera en hemlighet. Du har inte hemliga förfallohändelser att hantera, och du har inte samma risknivå som kan vara förknippad med att avslöja eller läcka den hemligheten.

Med identiteten kan du skapa en federerad identitetsautentiseringsuppgift som kan användas i stället för en klienthemlighet som en klientkontroll. Den här metoden är endast tillgänglig för personalkonfigurationer. Den inbyggda autentiseringsfunktionen stöder för närvarande federerade identitetsuppgifter som förhandsversion.

Du kan använda stegen i det här avsnittet för att konfigurera din App Service- eller Azure Functions-resurs så att den använder det här mönstret. Stegen här förutsätter att du redan har konfigurerat en appregistrering med någon av de metoder som stöds och att du redan har definierat en hemlighet.

  1. Skapa en användartilldelad hanterad identitetsresurs enligt dessa instruktioner.

  2. Tilldela den identiteten till din App Service- eller Azure Functions-resurs.

    Viktigt!

    Den användartilldelade hanterade identiteten som du skapar bör endast tilldelas till App Service- eller Azure Functions-programmet genom den här registreringen. Om du tilldelar identiteten till en annan resurs ger du resursen onödig åtkomst till din appregistrering.

  3. Anteckna värdena för objekt-ID och klient-ID för den hanterade identiteten. Du behöver objekt-ID:t för att skapa en federerad identitetsautentiseringsuppgift i nästa steg. Du använder den hanterade identitetens klient-ID i ett senare steg.

  4. Följ anvisningarna i Microsoft Entra-ID för att konfigurera en federerad identitetsautentiseringsuppgift i ett befintligt program. Dessa instruktioner innehåller även avsnitt för uppdatering av programkod, som du kan hoppa över.

  5. Lägg till en ny programinställning med namnet OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Ange dess värde till den hanterade identitetens klient-ID-värde som du fick i ett tidigare steg. Använd inte klient-ID:t för din appregistrering. Se till att markera denna programinställning som slot-sticky.

  6. I de inbyggda autentiseringsinställningarna för din appresurs anger du Namnet på inställningen Klienthemlighet till OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

    Så här gör du den här ändringen med hjälp av Azure-portalen:

    1. Gå tillbaka till din App Service- eller Azure Functions-resurs och välj fliken Autentisering .
    2. I avsnittet Identitetsprovider väljer du ikonen i kolumnen Redigera för Microsoft-posten.
    3. I dialogrutan Redigera identitetsprovider öppnar du listrutan för namnet på inställningen Klienthemlighet och väljer OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.
    4. Välj Spara.

    Så här gör du den här ändringen med hjälp av REST-API:et:

    • Ange egenskapen clientSecretSettingName till OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Du hittar den här egenskapen under properties>identityProviders>azureActiveDirectory>registration.

  7. Kontrollera att programmet fungerar som förväntat. Du bör kunna utföra en ny inloggningsåtgärd.

När du är nöjd med beteendet med hjälp av en hanterad identitet tar du bort den befintliga hemligheten:

  1. Kontrollera att appkoden inte är beroende av programinställningen. Om den gör det följer du anvisningarna för att uppdatera programkoden för att begära en åtkomsttoken.

  2. Ta bort programinställningen som tidigare innehöll din hemlighet. Namnet på den här programinställningen är det tidigare värdet för klienthemlighetsinställningen innan du anger det till OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

  3. Logga in på administrationscentret för Microsoft Entra genom att använda klienten som innehåller din app-registrering. Gå till appregistreringen igen.

  4. Under Certifikat och hemligheter väljer du Klienthemligheter och tar bort klienthemligheten.

Din app är nu konfigurerad för att använda Microsoft Entra-ID-autentisering utan hemligheter.

Konfigurera klientappar för åtkomst till App Service

I tidigare avsnitt har du registrerat din App Service- eller Azure Functions-app för att autentisera användare. I följande avsnitt beskrivs hur du registrerar interna klienter eller daemon-appar i Microsoft Entra. Dessa klienter eller appar kan begära åtkomst till API:er som exponeras av App Service för användare eller sig själva, till exempel i en N-nivåarkitektur. Om du bara vill autentisera användare krävs inte stegen i följande avsnitt.

Internt klientprogram

Du kan registrera interna klienter för att begära åtkomst till App Service-appens API:er för en inloggad användare:

  1. På menyn i Azure-portalen väljer du Microsoft Entra-ID.

  2. I den vänstra rutan väljer du Hantera>appregistreringar. Välj sedan Ny registrering.

  3. I fönstret Registrera ett program för Namn anger du ett namn för din appregistrering.

  4. I Omdirigerings-URI väljer du Offentlig klient/intern (mobil och skrivbord) och anger omdirigerings-URL:en. Ange till exempel https://contoso.azurewebsites.net/.auth/login/aad/callback.

  5. Välj Registrera.

  6. När appregistreringen har skapats kopierar du värdet för program-ID (klient-ID).

    Anteckning

    För ett Microsoft Store-program använder du paket-SID som URI i stället.

  7. I den vänstra rutan väljer du Hantera>API-behörigheter. Välj sedan Lägg till en behörighet>Mina API:er.

  8. Välj den appregistrering som du skapade tidigare för din App Service-app. Om du inte ser appregistreringen, se till att lägga till omfånget user_impersonation i appregistreringen.

  9. Under Delegerade behörigheter väljer du user_impersonation och sedan Lägg till behörigheter.

Nu har du konfigurerat ett internt klientprogram som kan begära åtkomst till din App Service-app för en användares räkning.

Daemon-klientprogram (tjänst-till-tjänst-anrop)

I en N-nivåarkitektur kan klientprogrammet hämta en token för att anropa en App Service- eller Azure Functions-app för själva klientappens räkning, inte för en användares räkning. Det här scenariot är användbart för icke-interaktiva daemonprogram som utför uppgifter utan en inloggad användare. Den använder OAuth 2.0-klientens standardautentiseringsuppgifter. Mer information finns i Microsofts identitetsplattform och OAuth 2.0-klientautentiseringsflöde.

  1. På menyn i Azure-portalen väljer du Microsoft Entra-ID.

  2. I den vänstra rutan väljer du Hantera>appregistreringar. Välj sedan Ny registrering.

  3. I fönstret Registrera ett program för Namn anger du ett namn för din appregistrering.

  4. För ett daemonprogram behöver du ingen omdirigerings-URI, så du kan hålla rutan Omdirigerings-URI tom.

  5. Välj Registrera.

  6. När appregistreringen har skapats kopierar du värdet för program-ID (klient-ID).

  7. I den vänstra rutan väljer du Hantera>certifikat och hemligheter. Välj sedan Klienthemligheter>Ny klienthemlighet.

  8. Ange en beskrivning och förfallodatum och välj sedan Lägg till.

  9. I fältet Värde kopierar du klienthemlighetsvärdet. När du har flyttat bort från den här sidan visas den inte igen.

Nu kan du begära en åtkomsttoken med hjälp av klient-ID och klienthemlighet. Ange parametern resource till URI-värdet för program-ID för målappen. Den resulterande åtkomsttoken kan sedan visas för målappen via standardhuvudet för OAuth 2.0-auktorisering. App Service-autentisering validerar och använder token för att indikera att anroparen är autentiserad. I det här fallet är anroparen ett program, inte en användare.

Med den här metoden kan alla klientprogram i din Microsoft Entra-klientorganisation begära en åtkomsttoken och autentisera till målappen. Om du också vill framtvinga auktorisering för att endast tillåta vissa klientprogram måste du utföra extra konfiguration.

  1. Definiera en approll i manifestet för appregistreringen som representerar den App Service- eller Azure Functions-app som du vill skydda.

  2. På den appregistrering som representerar klienten som måste auktoriseras väljer du API-behörigheter>>

  3. Välj den appregistrering som du skapade tidigare. Om du inte ser appregistreringen kontrollerar du att du har lagt till en app-roll.

  4. Under Programbehörigheter väljer du den apparoll som du skapade tidigare. Välj Lägg till behörigheter.

  5. Välj Bevilja administratörsmedgivande för att auktorisera klientprogrammet för att begära behörigheten.

    På samma sätt som i föregående scenario (innan du lade till några roller) kan du nu begära en åtkomsttoken för samma målresurs. Åtkomsttoken innehåller ett roles uttryck som innehåller de applikationsroller som är auktoriserade till klientprogrammet.

I appkoden för App Service eller Azure Functions kan du nu verifiera att token har de förväntade rollerna. App Service-autentisering utför inte den här valideringen. Mer information finns i Åtkomst till användaranspråk i appkod.

Nu har du konfigurerat ett daemonklientprogram som kan komma åt din App Service-app med hjälp av sin egen identitet.

Bästa praxis

Oavsett vilken konfiguration du använder för att konfigurera autentisering, skyddar följande metodtips din klientorganisation och dina program på ett säkrare sätt:

  • Konfigurera varje App Service-app med en egen appregistrering i Microsoft Entra.
  • Ge varje App Service-app sina egna behörigheter och medgivande.
  • Undvik behörighetsdelning mellan miljöer. Använd separata appregistreringar för separata distributionsplatser. När du testar ny kod kan den här metoden hjälpa till att förhindra att problem påverkar produktionsappen.

Migrera till Microsoft Graph

Vissa äldre appar kan ha konfigurerats med ett beroende av Azure AD Graph, som är föråldrat och planerat att tas ur bruk helt. Din appkod kan till exempel anropa Azure AD Graph för att kontrollera gruppmedlemskap som en del av ett auktoriseringsfilter i en pipeline för mellanprogram. Appar bör flyttas till Microsoft Graph. Mer information finns i Migrera dina appar från Azure AD Graph till Microsoft Graph.

Under den här migreringen kan du behöva göra vissa ändringar i konfigurationen av App Service-autentisering. När du har lagt till Microsoft Graph-behörigheter i din appregistrering kan du:

  • Uppdatera utfärdarens URL-värde så att det inkluderar suffixet /v2.0 om det inte redan gör det.

  • Ta bort begäranden om Azure AD Graph-behörigheter från din inloggningskonfiguration. Vilka egenskaper som ska ändras beror på vilken version av hanterings-API:et du använder:

    • Om du använder V1-API:et (/authsettings) finns den här inställningen i matrisen additionalLoginParams .
    • Om du använder V2-API:et (/authsettingsV2) finns den här inställningen i matrisen loginParameters .

    Du måste till exempel ta bort alla referenser till https://graph.windows.net. Den här ändringen innehåller parametern resource som /v2.0 slutpunkten inte stöder. Den innehåller även alla omfång som du specifikt begär från Azure AD Graph.

    Du måste också uppdatera konfigurationen för att begära de nya Microsoft Graph-behörigheter som du har konfigurerat för programregistreringen. I många fall kan du använda standardomfånget för att förenkla den här installationen. Det gör du genom att lägga till en ny inloggningsparameter: scope=openid profile email https://graph.microsoft.com/.default.

Med dessa ändringar, när App Service-autentisering försöker logga in, begär den inte längre behörigheter till Azure AD Graph. I stället hämtar den en token för Microsoft Graph. All användning av denna token från programkoden måste också uppdateras, enligt beskrivningen i Migrera dina appar från Azure AD Graph till Microsoft Graph.

Relaterat innehåll