Share via

Programtyper i v1.0

  • Artikel

Varning

Det här innehållet gäller för den äldre Azure AD v1.0-slutpunkten. Använd Microsofts identitetsplattform för nya projekt.

Azure Active Directory (Azure AD) stöder autentisering för en mängd olika moderna apparkitekturer, som alla baseras på branschstandardprotokollen OAuth 2.0 eller OpenID Connect.

Följande diagram illustrerar scenarier och programtyper och hur olika komponenter kan läggas till:

Programtyper och scenarier

Det här är de fem primära programscenarierna som stöds av Azure AD:

Följ länkarna för att lära dig mer om varje typ av app och förstå scenarier på hög nivå innan du börjar arbeta med koden. Du kan också lära dig om de skillnader du behöver veta när du skriver en viss app som fungerar med v1.0-slutpunkten eller v2.0-slutpunkten.

Anteckning

V2.0-slutpunkten stöder inte alla Azure AD scenarier och funktioner. Om du vill avgöra om du ska använda v2.0-slutpunkten läser du om v2.0-begränsningar.

Du kan utveckla alla appar och scenarier som beskrivs här med hjälp av olika språk och plattformar. De backas upp av fullständiga kodexempel som är tillgängliga i kodexempelguiden: v1.0-kodexempel efter scenario och v2.0-kodexempel efter scenario. Du kan också ladda ned kodexemplen direkt från motsvarande GitHub-exempellagringsplatser.

Om ditt program dessutom behöver en specifik del eller ett segment i ett scenario från slutpunkt till slutpunkt kan funktionerna i de flesta fall läggas till oberoende av varandra. Om du till exempel har ett internt program som anropar ett webb-API kan du enkelt lägga till ett webbprogram som även anropar webb-API:et.

Appregistrering

Registrera en app som använder slutpunkten Azure AD v1.0

Alla program som outsourcar autentisering till Azure AD måste registreras i en katalog. Det här steget handlar om att berätta för Azure AD om ditt program, inklusive URL:en där det finns, URL:en för att skicka svar efter autentisering, URI:n för att identifiera ditt program med mera. Den här informationen krävs av några viktiga orsaker:

  • Azure AD måste kommunicera med programmet när du hanterar inloggning eller utbyte av token. Informationen som skickas mellan Azure AD och programmet innehåller följande:

    • Program-ID-URI – identifieraren för ett program. Det här värdet skickas till Azure AD under autentiseringen för att ange vilket program anroparen vill ha en token för. Dessutom ingår det här värdet i token så att programmet vet att det var det avsedda målet.
    • Svars-URL och omdirigerings-URI – För ett webb-API eller ett webbprogram är svars-URL:en den plats där Azure AD skickar autentiseringssvaret, inklusive en token om autentiseringen lyckades. För ett internt program är omdirigerings-URI:n en unik identifierare som Azure AD omdirigerar användaragenten till i en OAuth 2.0-begäran.
    • Program-ID – ID:t för ett program, som genereras av Azure AD när programmet är registrerat. När du begär en auktoriseringskod eller token skickas program-ID och nyckel till Azure AD under autentiseringen.
    • Nyckel – Nyckeln som skickas tillsammans med ett program-ID när du autentiserar till Azure AD för att anropa ett webb-API.

  • Azure AD måste se till att programmet har de behörigheter som krävs för att komma åt dina katalogdata, andra program i din organisation och så vidare.

Mer information finns i registrera en app.

Appar för en klientorganisation och flera klientorganisationer

Etableringen blir tydligare när du förstår att det finns två kategorier av program som kan utvecklas och integreras med Azure AD:

  • Program för enskild klientorganisation – Ett program för en enda klientorganisation är avsett att användas i en organisation. Dessa är vanligtvis verksamhetsspecifika (LoB) program som skrivits av en företagsutvecklare. Ett enda klientprogram behöver bara nås av användare i en katalog, och därför behöver det bara etableras i en katalog. Dessa program registreras vanligtvis av en utvecklare i organisationen.
  • Program för flera innehavare – Ett program för flera innehavare är avsett att användas i många organisationer, inte bara en organisation. Det kallas vanligen för SaaS-webbprogram (Software as a Service) och skrivs av en oberoende programvaruleverantör (ISV). Program med flera klientorganisationer måste etableras i varje katalog där de ska användas, vilket kräver användarens eller administratörens medgivande för att registrera dem. Medgivandeprocessen startar när ett program har registrerats i katalogen och ges åtkomst till Graph API eller kanske någon annan webb-API. När en användare eller administratör från en annan organisation registrerar sig för att använda programmet visas en dialogruta som visar de behörigheter som programmet kräver. Användaren eller administratören kan sedan godkänna programmet, vilket ger programmet åtkomst till angivna data och slutligen registrerar programmet i deras katalog. Mer information finns i Översikt över ramverket för medgivande.

Ytterligare överväganden när du utvecklar appar för en enskild klientorganisation eller flera klientorganisationer

Vissa ytterligare överväganden uppstår när du utvecklar ett program för flera klientorganisationer i stället för ett enda klientprogram. Om du till exempel gör ditt program tillgängligt för användare i flera kataloger behöver du en mekanism för att avgöra vilken klientorganisation de finns i. Ett program för en enskild klientorganisation behöver bara titta i en egen katalog för en användare, medan ett program med flera klientorganisationer måste identifiera en specifik användare från alla kataloger i Azure AD. För att utföra den här uppgiften tillhandahåller Azure AD en gemensam autentiseringsslutpunkt där alla program med flera klientorganisationer kan dirigera inloggningsbegäranden i stället för en klientspecifik slutpunkt. Den här slutpunkten är https://login.microsoftonline.com/common för alla kataloger i Azure AD, medan en klientspecifik slutpunkt kan vara https://login.microsoftonline.com/contoso.onmicrosoft.com. Den gemensamma slutpunkten är särskilt viktig att tänka på när du utvecklar ditt program eftersom du behöver den logik som krävs för att hantera flera klienter under inloggning, utloggning och tokenvalidering.

Om du håller på att utveckla ett enda klientprogram men vill göra det tillgängligt för många organisationer kan du enkelt göra ändringar i programmet och dess konfiguration i Azure AD för att göra det möjligt för flera klientorganisationer. Dessutom använder Azure AD samma signeringsnyckel för alla token i alla kataloger, oavsett om du tillhandahåller autentisering i en enda klientorganisation eller ett program med flera klientorganisationer.

Varje scenario som anges i det här dokumentet innehåller ett underavsnitt som beskriver dess etableringskrav. Mer detaljerad information om hur du etablerar ett program i Azure AD och skillnaderna mellan program med en och flera klientorganisationer finns i Integrera program med Azure Active Directory för mer information. Fortsätt läsa för att förstå de vanliga programscenarierna i Azure AD.

Nästa steg