Identitets- och kontotyper för appar med en och flera klientorganisationer

I den här artikeln förklaras hur du som utvecklare kan välja om din app endast tillåter användare från din Microsoft Entra-klientorganisation, alla Microsoft Entra-klientorganisationer eller användare med personliga Microsoft-konton. Du kan konfigurera din app så att den antingen är enskild klientorganisation eller multitenant under appregistreringen i Azure. Se till att Nolltillit principen om åtkomst med minst behörighet så att appen endast begär behörigheter som den behöver.

Microsofts identitetsplattform ger stöd för specifika identitetstyper:

• Arbets- eller skolkonton när entiteten har ett konto i ett Microsoft Entra-ID
• Microsofts personliga konton (MSA) för alla som har konto i Outlook.com, Hotmail, Live, Skype, Xbox osv.
• Externa identiteter i Microsoft Entra-ID för partner (användare utanför organisationen)
• Microsoft Entra Business to Customer (B2C) som gör att du kan skapa en lösning som låter dina kunder ta in sina andra identitetsprovidrar. Program som använder Azure AD B2C eller prenumererar på Microsoft Dynamics 365 Fraud Protection med Azure Active Directory B2C kan utvärdera potentiellt bedräglig aktivitet efter försök att skapa nya konton eller logga in på klientens ekosystem.

En obligatorisk del av programregistreringen i Microsoft Entra-ID är ditt val av kontotyper som stöds. Medan IT-proffs i administratörsroller bestämmer vem som kan samtycka till appar i deras klientorganisation, anger du som utvecklare vem som kan använda din app baserat på kontotyp. När en klientorganisation inte tillåter att du registrerar ditt program i Microsoft Entra-ID ger administratörer dig ett sätt att förmedla informationen till dem via en annan mekanism.

Du väljer bland följande alternativ för kontotyp som stöds när du registrerar ditt program.

• Accounts in this organizational directory only (O365 only - Single tenant)
• Accounts in any organizational directory (Any Azure AD directory - Multitenant)
• Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
• Personal Microsoft accounts only

Endast konton i den här organisationskatalogen – enskild klientorganisation

När du väljer Endast konton i den här organisationskatalogen (endast O365 – enskild klient)tillåter du endast användare och gäster från klientorganisationen där utvecklaren har registrerat sin app. Det här alternativet är det vanligaste för verksamhetsspecifika program (LOB).

Endast konton i en organisationskatalog – flera klientorganisationer

När du väljer Konton i en organisationskatalog (Alla Microsoft Entra-kataloger – Multitenant)tillåter du att alla användare från valfri Microsoft Entra-katalog loggar in på ditt program för flera klientorganisationer. Om du bara vill tillåta användare från specifika klienter filtrerar du dessa användare i koden genom att kontrollera att tid-anspråket i id_token finns i listan över tillåtna klienter. Ditt program kan använda organisationens slutpunkt eller den gemensamma slutpunkten för att logga in användare i användarens hemklientorganisation. För att stödja gästanvändare som loggar in på din app för flera klienter använder du den specifika klientslutpunkten för klientorganisationen där användaren är gäst för att logga in användaren.

Konton i alla organisationskonton och personliga Microsoft-konton

När du väljer Konton i ett organisationskonto och personliga Microsoft-konton (Alla Microsoft Entra-kataloger – Multitenant) och personliga Microsoft-konton (t.ex. Skype, Xbox), tillåter du att en användare loggar in på ditt program med sin interna identitet från alla Microsoft Entra-klient- eller konsumentkonton. Samma klientfiltrering och slutpunktsanvändning gäller för dessa appar som för appar med flera klienter enligt beskrivningen ovan.

Endast personliga Microsoft-konton

När du väljer Personliga Microsoft-konton tillåter du endast användare med konsumentkonton att använda din app.

Kundinriktade program

När du skapar en lösning i Microsofts identitetsplattform som når ut till dina kunder vill du vanligtvis inte använda företagskatalogen. I stället vill du att kunderna ska vara i en separat katalog så att de inte kan komma åt företagets företagsresurser. För att uppfylla detta behov erbjuder Microsoft Microsoft Entra Business to Customer (B2C).

Azure AD B2C tillhandahåller företags-till-kund-identitet som en tjänst. Du kan tillåta användare att ha ett användarnamn och lösenord bara för din app. B2C stöder kunder med sociala identiteter för att minska lösenord. Du kan stödja företagskunder genom att federera din Azure AD B2C-katalog till dina kunders Microsoft Entra-ID (eller någon identitetsprovider som stöder SAML) till OpenID Anslut. Till skillnad från en app för flera klientorganisationer använder appen inte kundens företagskatalog där de skyddar sina företagstillgångar. Dina kunder kan komma åt din tjänst eller funktion utan att ge din app åtkomst till företagets resurser.

Det är inte bara upp till utvecklaren

Medan du definierar i din programregistrering vem som kan logga in på din app, kommer det sista meddelandet från den enskilda användaren eller administratörerna för användarens hemklientorganisation. Klientadministratörer vill ofta ha mer kontroll över en app än bara vem som kan logga in. De kanske till exempel vill tillämpa en princip för villkorsstyrd åtkomst på appen eller styra vilken grupp de tillåter att programmet används. För att göra det möjligt för klientadministratörer att ha den här kontrollen finns det ett andra objekt i Microsofts identitetsplattform: Enterprise-appen. Företagsappar kallas även för tjänstens huvudnamn.

För appar med användare i andra klientorganisationer eller andra konsumentkonton

Som du ser i diagrammet nedan med hjälp av ett exempel på två klientorganisationer (för fiktiva organisationer, Adatum och Contoso), innehåller kontotyper som stöds kontotyperna Konton i valfri organisationskatalog för ett program med flera klientorganisationer så att du kan tillåta organisationskataloganvändare. Med andra ord tillåter du att en användare loggar in i ditt program med sin interna identitet från alla Microsoft Entra-ID:n. Tjänstens huvudnamn skapas automatiskt i klientorganisationen när den första användaren från en klientorganisation autentiserar till appen.

Den animerade GIF-filen visar två diagram med en rörelseövergång mellan det första diagrammet och det andra diagrammet. Första diagramrubriken: Tjänstens huvudnamn skapas automatiskt i klientorganisationen när den första användaren från en klientorganisation autentiserar till appen. Under den första diagramrubriken till vänster finns två punkter: Endast en programregistrering eller ett programobjekt. Företagsapp, tjänstens huvudnamn, i varje klientorganisation som gör att användaren kan logga in på appen. Till vänster om punktpunkterna representerar en molnform Adatum-klientorganisationen där Adatum är namnet på en fiktiv organisation. I molnformen Adatum-klientorganisation representerar en ikon appen och en annan ikon representerar Adatum SP. En pil ansluter appikonen till SP-ikonen. Andra diagramrubriken: Innehavaradministratören styr hur appen fungerar i deras klientorganisation med Enterprise-appen för den appen. Under den andra diagramrubriken till vänster representerar en molnform Adatum-klientorganisationen där Adatum är namnet på en fiktiv organisation. Till höger om molnformen Adatum representerar en annan molnform Contoso-klientorganisationen där Contoso är namnet på en fiktiv organisation. Inuti Contoso-molnformen representerar en ikon Contoso SP. En pil ansluter Adatum-appen inuti Adatum-molnformen till Contoso SP inuti Contoso-molnformen.

Det finns bara ett programregistrerings- eller programobjekt. Men en Enterprise-app eller tjänstens huvudnamn (SP) i varje klientorganisation tillåter användare att logga in på appen. Klientadministratören kan styra hur appen fungerar i deras klientorganisation.

Överväganden för flera klientappar

Appar med flera klienter loggar in användare från användarens hemklientorganisation när appen använder den gemensamma slutpunkten eller organisationsslutpunkten. Appen har en appregistrering enligt diagrammet nedan. I det här exemplet registreras programmet i Adatum-klientorganisationen. Användare A från Adatum och Användare B från Contoso kan båda logga in i appen med förväntan att användare A från Adatum kommer åt Adatum-data och att användare B från Contoso kommer åt Contoso-data.

Diagramrubrik: Multitenant-app jämfört med externa identiteter, även kallat B 2 B. Till vänster visas "Adatum" ovanför en byggnad för att representera Adatum-organisationen där Adatum är namnet på en fiktiv organisation. Till höger visas "Contoso" ovanför en byggnad för att representera Contoso-organisationen där Contoso är namnet på en fiktiv organisation. Till höger om Adatum-byggnaden finns en ruta med rubriken Adatum App Registration. Den innehåller en ikon som representerar Adatum-data till vänster och en ikon som representerar Contoso-data till höger. En pil ansluter Adatum-byggnaden till rutan Appregistrering för Adatum. I Adatum-byggnaden representerar en cirkel användare A. En pil ansluter användare A till rutan Registrering av Adatum-appar. Inuti Contoso-byggnaden representerar en cirkel användare B. En pil ansluter användare B till rutan Adatum-appregistrering. Text längst ned i diagrammet, mellan de två byggnaderna: Multitenant-appen. Använder gemensam slutpunkt för att logga in. Ingen inbjudan/externt konto behövs.

Som utvecklare är det ditt ansvar att hålla klientinformationen separat. Om Contoso-data till exempel kommer från Microsoft Graph ser användare B från Contoso bara Contosos Microsoft Graph-data. Det finns ingen möjlighet för användare B från Contoso att komma åt Microsoft Graph-data i Adatum-klientorganisationen eftersom Microsoft 365 har verklig dataavgränsning.

I diagrammet ovan kan användare B från Contoso logga in på programmet och få åtkomst till Contoso-data i ditt program. Ditt program kan använda våra vanliga (eller organisations) slutpunkter så att användaren loggar in internt till sin klientorganisation, vilket inte kräver någon inbjudansprocess. En användare kan köra och logga in på ditt program och det fungerar när användaren eller klientadministratören har gett sitt medgivande.

Samarbete med externa användare

När företag vill göra det möjligt för användare som inte är medlemmar i företaget att komma åt data från företaget använder de funktionen Microsoft Entra Business to Business (B2B). Som visas i diagrammet nedan kan företag bjuda in användare att bli gästanvändare i sin klientorganisation. När användaren har accepterat inbjudan kan de komma åt data som den inbjudande klientorganisationen har skyddat. Användaren skapar inte en separat autentiseringsuppgift i klientorganisationen.

Diagramrubrik: Multitenant-app jämfört med externa identiteter, även kallat B 2 B. Till vänster visas "Adatum" ovanför en byggnad som representerar Adatum-organisationen. Till höger visas "Contoso" ovanför en byggnad som representerar Contoso-organisationen. Inuti Contoso-byggnaden finns en cirkel som representerar användare B. Till höger om Adatum-byggnaden representerar en ruta som innehåller en ikon Adatum-data och appregistrering. En pil ansluter Adatum-byggnaden till data- och registreringsrutan. Inuti Adatum-byggnaden representerar en cirkel användare A. En pil ansluter användare A till data- och registreringsrutan. En mindre cirkel inuti Adatum-byggnaden ansluter med en pil till användare B och med en annan pil till data- och registreringsrutan. Text längst ned i diagrammet, mellan de två byggnaderna: Externa identiteter. Använd Adatum-slutpunkten för att logga in. Det går inte att använda en vanlig slutpunkt. Inbjudan/externt konto behövs.

Gästanvändare autentiserar genom att logga in på sin hemklientorganisation, personliga Microsoft-konto eller något annat IDP-konto. Du kan också autentisera med ett engångslösenord med valfri e-post. När gästerna har autentiserats ger den inbjudande klientens Microsoft Entra-ID en token för åtkomst till att bjuda in klientorganisationens data.

Som utvecklare bör du tänka på följande när ditt program stöder gästanvändare:

• Du måste använda en klientspecifik slutpunkt när du loggar in gästanvändaren. Du kan inte använda de vanliga slutpunkterna, organisationen eller konsumentslutpunkterna.
• Gästanvändarens identitet skiljer sig från användarens identitet i deras hemklientorganisation eller annan IDP. Anspråket oid i token för en gästanvändare skiljer sig från samma person oid i deras hemklientorganisation.

Nästa steg

• Hur och varför appar läggs till i Microsoft Entra-ID förklarar hur programobjekt beskriver ett program till Microsoft Entra-ID.
• Metodtips för säkerhet för programegenskaper i Microsoft Entra-ID omfattar egenskaper som omdirigerings-URI, åtkomsttoken, certifikat och hemligheter, program-ID-URI och programägarskap.
• Att skapa appar med en Nolltillit metod för identitet ger en översikt över behörigheter och metodtips för åtkomst.
• När du skaffar auktorisering för åtkomst till resurser kan du förstå hur du bäst kan säkerställa Nolltillit när du hämtar behörigheter för resursåtkomst för ditt program.
• Genom att utveckla en strategi för delegerade behörigheter kan du implementera den bästa metoden för att hantera behörigheter i ditt program och utveckla med hjälp av Nolltillit principer.
• Genom att utveckla en strategi för programbehörigheter kan du bestämma hur programmets behörigheter ska hanteras.