Share via

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

  • Artikel

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 först registrera det i en arbetsstyrka eller 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 arbetsstyrkan. 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 Autentisering 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 identitetsprovider för att logga in Microsoft- och Microsoft Entra-identiteter.

  4. Som Klientorganisationstyp väljer du Personalkonfiguration (aktuell klient) för anställda och företagsgäster eller väljer Extern konfiguration för konsumenter och företagskunder.

Välj appregistrering

Funktionen App Service-autentisering kan automatiskt skapa en appregistrering åt dig eller så kan du använda en registrering som du eller en katalogadministratör har skapat 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 din app finns i.
  • Alternativet att skapa en ny registrering är inte tillgängligt för myndighetsmoln.

Skapa och använd en ny appregistrering eller använd en befintlig registrering som skapats separat.

Alternativ 1: Skapa och använda en ny appregistrering

Använd det här alternativet om du inte behöver skapa en appregistrering separat. Du kan anpassa appregistreringen i Microsoft Entra när den har skapats.

Kommentar

Alternativet att skapa en ny registrering automatiskt är inte tillgängligt för myndighetsmoln. Definiera i stället en registrering separat.

Ange namnet på den nya appregistreringen.

Välj kontotypen Som stöds:

  • Aktuell klientorganisation – enskild klientorganisation. Endast konton i den här organisationskatalogen. 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.
  • Alla Microsoft Entra-kataloger – Multitenant. Konton i valfri organisationskatalog. Alla användare med ett arbets- eller skolkonto från Microsoft kan använda ditt program eller API. Detta 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 flera klientorganisationer.
  • Alla Microsoft Entra-kataloger och personliga Microsoft-konton. Konton i valfri organisationskatalog och personliga Microsoft-konton (till exempel Skype, 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 samt 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 och aktivera flera klientorganisationer.
  • 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 slot-sticky-programinställning med namnet MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Du kan uppdatera den inställningen senare för att använda Key Vault-referenser om du vill hantera hemligheten i Azure Key Vault.

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

Antingen:

  • Välj Välj en befintlig appregistrering i den här katalogen och välj en appregistrering i listrutan.
  • Välj Ange information om en befintlig appregistrering och ange:
    • Program-ID (klient).
    • Klienthemlighet (rekommenderas). Ett hemligt värde som programmet använder för att bevisa sin identitet när en token begärs. 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 inte rekommenderas* .
    • Utfärdarens URL, som har formuläret <authentication-endpoint>/<tenant-id>/v2.0. Ersätt <authentication-endpoint> med värdet för autentiseringsslutpunkten som är specifikt för molnmiljön. Till exempel skulle en personalklientorganisation i globala Azure använda "https://login.microsoftonline.com" som dess autentiseringsslutpunkt.

Om du behöver skapa en appregistrering manuellt i en personalklientorganisation följer du snabbstarten registrera ett program . 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 skriver <app-url>/.auth/login/aad/callback. Exempel: https://contoso.azurewebsites.net/.auth/login/aad/callback

När du har skapat den ändrar du appregistreringen:

  1. I det vänstra navigeringsfältet 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 kan begäras som beviljar åtkomst. Det används som ett prefix för omfång som du skapar.

    För en app med en enda klientorganisation kan du använda standardvärdet, som är i formuläret api://<application-client-id>. Du kan också ange en mer läsbar URI som https://contoso.com/api baseras 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 referensen för metodtips för appregistreringar.

  2. Välj Lägg till en omfattning.

    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 godkänna det här omfånget.
    3. I textrutorna anger du namnet på och beskrivningen för medgivandesomfånget som du vill att användarna ska se på medgivandesidan. Ange till exempel Åtkomstprogramnamn><.
    4. Välj Lägg till definitionsområde.

  3. (Rekommenderas) Så här skapar du en klienthemlighet:

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

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

Konfigurera ytterligare kontroller

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

För Krav för klientprogram väljer du om du vill:

  • 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 begäranden från utfärdarens klientorganisation
  • Tillåt begäranden från specifika klienter
  • Använd standardbegränsningar baserat på utfärdare

Din app kan fortfarande behöva fatta ytterligare auktoriseringsbeslut i kod. Mer information finns i Använda en inbyggd auktoriseringsprincip.

Konfigurera autentiseringsinställningar

De här alternativen avgör hur ditt program svarar på oautentiserade begäranden, och standardvalen omdirigerar alla begäranden för att logga in med den nya providern. Du kan ändra anpassa det här beteendet nu eller justera inställningarna senare från huvudskärmen för autentisering genom att välja Redigera bredvid Autentiseringsinställningar. Mer information om de här alternativen 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

  • HTTP 302 Hittades omdirigering: rekommenderas för webbplatser
  • HTTP 401 Obehörig: rekommenderas för API:er
  • HTTP 403 Förbjuden
  • HTTP 404 Hittades inte

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

Lägg till identitetsprovidern

Om du har valt personalkonfiguration kan du välja Nästa: Behörigheter och lägga till de Microsoft Graph-behörigheter som krävs av programmet. Dessa 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å skärmen 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 den här självstudien.

Auktorisera begäranden

Som standard hanterar App Service-autentisering endast autentisering, vilket avgör om anroparen är den som de säger att de är. Auktorisering, att avgöra om anroparen ska ha åtkomst till någon resurs, är ett extra steg utöver autentisering. Du kan lära dig mer om dessa begrepp från Microsofts identitetsplattform auktoriseringsgrunderna.

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

Dricks

Program med flera klientorganisationer 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 klientorganisationer verifieras inte vilken klientorganisation begäran kommer från. En app kan till exempel behöva begränsas till specifika klienter, baserat på om organisationen har registrerat sig för tjänsten. Se Microsofts identitetsplattform vägledning för flera klientorganisationer.

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. 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 vad du skulle se 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 den underliggande åtkomsttoken från den inmatade x-ms-token-aad-access-token rubriken.

Använda en inbyggd auktoriseringsprincip

Den skapade appregistreringen autentiserar inkommande begäranden för din Microsoft Entra-klientorganisation. Som standard tillåter det också vem som helst i klientorganisationen att komma åt programmet, vilket är bra för många program. Vissa program måste dock 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 App Service-autentiserings-V2-API:et. För närvarande är det enda sättet att konfigurera dessa inbyggda kontroller via 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 i följande struktur:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Property beskrivning
defaultAuthorizationPolicy En gruppering av krav som måste uppfyllas för att få å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 lista över klient-ID:t för strängprogram som representerar klientresursen som anropar till appen. När den här egenskapen har konfigurerats som en icke-et-matris godkänns endast token som hämtas av ett program som anges i listan.

Den här principen utvärderar eller azp anspråket appid för den inkommande token, som måste vara en åtkomsttoken. Se referensen för Microsofts identitetsplattform anspråk.
allowedPrincipals En gruppering av kontroller som avgör om huvudkontot som representeras av den inkommande begäran kan komma åt appen. Nöjdhet allowedPrincipals baseras på en logisk OR över 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-matris allowedPrincipals kan kravet uppfyllas om användaren eller programmet som representeras av begäran anges i listan. Det finns en gräns på totalt 500 tecken i listan över identiteter.

Den här principen utvärderar anspråket för oid den inkommande token. Se referensen för Microsofts identitetsplattform anspråk.

Dessutom kan vissa kontroller konfigureras via en programinställning, oavsett vilken API-version som används. Programinställningen WEBSITE_AUTH_AAD_ALLOWED_TENANTS kan konfigureras med en kommaavgränsad lista med upp till 10 klient-ID:t (till exempel "559a2f9c-c6f2-4d31-b8d6-5ad1a13f8330,5693f64a-3ad5-4be7-b846-e9d1141bcebc") för att kräva att den inkommande token kommer från en av de angivna klientorganisationer som anges av anspråket tid . Programinställningen WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL kan konfigureras till "true" eller "1" för att kräva att den inkommande token inkluderar ett oid anspråk. Den här inställningen ignoreras och behandlas som true om allowedPrincipals.identities den har konfigurerats (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 .

Konfigurera klientappar för åtkomst till din App Service

I föregående avsnitt registrerade du din App Service eller Azure-funktion för att autentisera användare. I det här avsnittet beskrivs hur du registrerar interna klienter eller daemonappar i Microsoft Entra så att de kan begära åtkomst till API:er som exponeras av din App Service för användare eller sig själva, till exempel i en N-nivåarkitektur. Att slutföra stegen i det här avsnittet krävs inte om du bara vill autentisera användare.

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å portalmenyn väljer du Microsoft Entra.

  2. I det vänstra navigeringsfältet väljer du Appregistreringar> Ny registrering.

  3. På sidan Registrera ett program anger du ett namn för din appregistrering.

  4. I Omdirigerings-URI väljer du Offentlig klient (mobil och skrivbord) och skriver URL:en <app-url>/.auth/login/aad/callback. 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).

    Kommentar

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

  7. I det vänstra navigeringsfältet väljer du API-behörigheter>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 kontrollerar du att du har lagt till user_impersonation omfånget 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 Funktionsapp för själva klientappens räkning (inte för en användare). 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 .

  1. På portalmenyn väljer du Microsoft Entra.
  2. I det vänstra navigeringsfältet väljer du Appregistreringar> Ny registrering.
  3. På sidan Registrera ett program anger du ett namn för din appregistrering.
  4. För ett daemonprogram behöver du ingen omdirigerings-URI så att du kan hålla den tom.
  5. Välj Registrera.
  6. När appregistreringen har skapats kopierar du värdet för program-ID (klient-ID).
  7. I det vänstra navigeringsfältet väljer du Certifikat och hemligheter>Klienthemligheter>Ny klienthemlighet.
  8. Ange en beskrivning och förfallodatum och välj Lägg till.
  9. I fältet Värde kopierar du klienthemlighetsvärdet. Den visas inte igen när du har navigerat bort från den här sidan.

Nu kan du begära en åtkomsttoken med hjälp av klient-ID och klienthemlighet genom att ange parametern resource till program-ID-URI :n för målappen. Den resulterande åtkomsttoken kan sedan visas för målappen med hjälp av standardhuvudet för OAuth 2.0-auktorisering, och App Service-autentisering verifierar och använder token som vanligt för att nu ange att anroparen (ett program i det här fallet inte en användare) har autentiserats.

För närvarande gör detta att alla klientprogram i din Microsoft Entra-klientorganisation kan 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 en extra konfiguration.

  1. Definiera en approll i manifestet för appregistreringen som representerar den App Service- eller Funktionsapp som du vill skydda.
  2. På appregistreringen som representerar klienten som måste auktoriseras väljer du API-behörigheter>Lägg till en behörighet>Mina API:er.
  3. Välj den appregistrering som du skapade tidigare. Om du inte ser appregistreringen kontrollerar du att du har lagt till en approll.
  4. Under Programbehörigheter väljer du den approll som du skapade tidigare och väljer sedan Lägg till behörigheter.
  5. Välj Bevilja administratörsmedgivande för att auktorisera klientprogrammet för att begära behörigheten.
  6. På samma sätt som i föregående scenario (innan några roller lades till) kan du nu begära en åtkomsttoken för samma mål resource, och åtkomsttoken innehåller ett roles anspråk som innehåller de approller som har auktoriserats för klientprogrammet.
  7. I appkoden för målappen eller funktionsappen kan du nu verifiera att de förväntade rollerna finns i token (detta utförs inte av App Service-autentisering). Mer information finns i Åtkomst till användaranspråk.

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

Bästa praxis

Oavsett vilken konfiguration du använder för att konfigurera autentiseringen 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 genom att använda separata appregistreringar för separata distributionsfack. 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 också ha konfigurerats med ett beroende av den inaktuella Azure AD Graph, som är schemalagd för fullständig tillbakadragning. Appkoden kan till exempel ha anropat 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 genom att följa de riktlinjer som tillhandahålls av Microsoft Entra som en del av Azure AD Graph-utfasningsprocessen. Om du följer dessa instruktioner 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:

  1. Uppdatera utfärdarens URL så att den innehåller suffixet "/v2.0" om den inte redan gör det.

  2. 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 detta i matrisen additionalLoginParams .
    • Om du använder V2-API:et (/authsettingsV2) finns detta i matrisen loginParameters .

    Du skulle till exempel behöva ta bort alla referenser till "https://graph.windows.net". Detta inkluderar parametern resource (som inte stöds av slutpunkten "/v2.0" eller eventuella omfång som du specifikt begär från Azure AD Graph.

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

När App Service-autentisering försöker logga in med dessa ändringar begär den inte längre behörigheter till Azure AD Graph, och i stället får den en token för Microsoft Graph. All användning av denna token från programkoden måste också uppdateras enligt vägledningen från Microsoft Entra.

Nästa steg