Översikt över behörigheter och medgivande i Microsoft platforma za identitete
För att få åtkomst till en skyddad resurs som e-post- eller kalenderdata behöver ditt program resursägarens auktorisering. Resursägaren kan samtycka till eller neka appens begäran. Genom att förstå dessa grundläggande begrepp kan du skapa säkrare och tillförlitligare program som endast begär den åtkomst de behöver, när de behöver det, från användare och administratörer.
Åtkomstscenarier
Som programutvecklare måste du identifiera hur programmet kommer åt data. Programmet kan använda delegerad åtkomst, agera på uppdrag av en inloggad användare eller endast appåtkomst, som endast fungerar som programmets egen identitet.
Delegerad åtkomst (åtkomst för en användares räkning)
I det här åtkomstscenariot har en användare loggat in på ett klientprogram. Klientprogrammet kommer åt resursen för användarens räkning. Delegerad åtkomst kräver delegerade behörigheter. Både klienten och användaren måste ha behörighet att göra begäran separat. Mer information om scenariot med delegerad åtkomst finns i scenariot för delegerad åtkomst.
För klientappen måste rätt delegerade behörigheter beviljas. Delegerade behörigheter kan också kallas omfång. Omfång är behörigheter för en viss resurs som representerar vad ett klientprogram kan komma åt för användarens räkning. Mer information om omfång finns i omfång och behörigheter.
För användaren förlitar sig auktoriseringen på de behörigheter som användaren har beviljats för att de ska få åtkomst till resursen. Användaren kan till exempel ha behörighet att komma åt katalogresurser av rollbaserad åtkomstkontroll i Microsoft Entra (RBAC) eller att få åtkomst till e-post- och kalenderresurser via Exchange Online RBAC. Mer information om RBAC för program finns i RBAC för program.
Åtkomst endast för appar (åtkomst utan användare)
I det här åtkomstscenariot agerar programmet på egen hand utan att användaren är inloggad. Programåtkomst används i scenarier som automatisering och säkerhetskopiering. Det här scenariot innehåller appar som körs som bakgrundstjänster eller daemoner. Det är lämpligt när det inte är önskvärt att ha en specifik användare inloggad, eller när de data som krävs inte kan begränsas till en enskild användare. Mer information om scenariot med endast appåtkomst finns i App-only-access.
Endast appåtkomst använder approller i stället för delegerade omfång. När de beviljas via medgivande kan approller även kallas programbehörigheter. Klientappen måste beviljas lämpliga programbehörigheter för den resursapp som den anropar. När den har beviljats kan klientappen komma åt begärda data. Mer information om hur du tilldelar approller till klientprogram finns i Tilldela approller till program.
Typer av behörigheter
Delegerade behörigheter används i scenariot med delegerad åtkomst. De är behörigheter som gör att programmet kan agera för en användares räkning. Programmet kommer aldrig att kunna komma åt något som den inloggade användaren själv inte kunde komma åt.
Ta till exempel ett program som har beviljats delegerad Files.Read.All
behörighet för användarens räkning. Programmet kan bara läsa filer som användaren kan komma åt personligen.
Programbehörigheter, även kallade approller, används i scenariot för endast appåtkomst, utan att en inloggad användare finns. Programmet kommer att kunna komma åt alla data som behörigheten är associerad med.
Till exempel kan ett program som beviljats Microsoft Graph API:s programbehörighet Files.Read.All
läsa alla filer i klientorganisationen med hjälp av Microsoft Graph. I allmänhet kan endast en administratör eller ägare av ett API:s tjänsthuvudnamn samtycka till programbehörigheter som exponeras av api:et.
Jämförelse av delegerade behörigheter och programbehörigheter
Behörighetstyper | Delegerade behörigheter | Programbehörigheter |
---|---|---|
Apptyper | Webb/mobil/ensidesapp (SPA) | Webb/daemon |
Åtkomstkontext | Få åtkomst för en användares räkning | Få åtkomst utan en användare |
Vem kan ge medgivande | – Användare kan samtycka till sina data – Administratörer kan godkänna alla användare |
Endast administratören kan ge medgivande |
Medgivandemetoder | – Statisk: konfigurerad lista över appregistrering – Dynamisk: begär individuella behörigheter vid inloggning |
– ENDAST statisk: konfigurerad lista över appregistrering |
Andra namn | -Scope – OAuth2-behörighetsomfång |
– Approller – Endast appbehörigheter |
Resultat av medgivande (specifikt för Microsoft Graph) | OAuth2PermissionGrant | appRoleAssignment |
Samtycke
Ett sätt att bevilja program behörigheter är genom medgivande. Medgivande är en process där användare eller administratörer ger ett program åtkomst till en skyddad resurs. När en användare till exempel försöker logga in på ett program för första gången kan programmet begära behörighet att se användarens profil och läsa innehållet i användarens postlåda. Användaren ser listan över behörigheter som appen begär via en medgivandeprompt. Andra scenarier där användare kan se en fråga om medgivande är:
- När tidigare beviljat medgivande återkallas.
- När programmet kodas för att specifikt fråga efter medgivande under inloggningen.
- När programmet använder dynamiskt medgivande för att be om nya behörigheter efter behov vid körning.
Viktig information om en medgivandeprompt är listan över behörigheter som programmet kräver och utgivarens information. Mer information om medgivandeprompten och medgivandeupplevelsen för både administratörer och slutanvändare finns i programmets medgivandeupplevelse.
Användarmedgivande
Användarmedgivande sker när en användare försöker logga in på ett program. Användaren tillhandahåller sina inloggningsuppgifter, som kontrolleras för att avgöra om medgivande redan har beviljats. Om det inte finns någon tidigare post med användar- eller administratörsmedgivande för de behörigheter som krävs visas en uppmaning om medgivande och uppmanas att bevilja programmet de begärda behörigheterna. En administratör kan behöva bevilja medgivande för användarens räkning.
Administratörsmedgivande
Beroende på vilka behörigheter de behöver kan vissa program kräva att en administratör är den som beviljar medgivande. Till exempel kan programbehörigheter och många delegerade behörigheter med hög behörighet endast godkännas av en administratör.
Administratörer kan bevilja medgivande för sig själva eller för hela organisationen. Mer information om användar- och administratörsmedgivande finns i Översikt över användar- och administratörsmedgivande.
Autentiseringsbegäranden uppmanas om administratörsmedgivande om medgivande inte har beviljats och om någon av dessa behörigheter med hög behörighet begärs.
Behörighetsbegäranden som innehåller anpassade programomfattningar betraktas inte som högprivilegier och därför kräver de inte administratörsmedgivande.
Förauktorisering
Med förauktorisering kan en resursprogramägare bevilja behörigheter utan att användarna behöver se en uppmaning om medgivande för samma uppsättning behörigheter som har förauktoriserats. På så sätt kommer ett program som har förauktoriserats inte att be användarna att samtycka till behörigheter. Resursägare kan förauktorisera klientappar i Azure-portalen eller med hjälp av PowerShell och API:er, till exempel Microsoft Graph.
Andra auktoriseringssystem
Ramverket för medgivande är bara ett sätt för ett program eller en användare att få åtkomst till skyddade resurser. Administratörer bör känna till andra auktoriseringssystem som kan ge åtkomst till känslig information. Exempel på olika auktoriseringssystem på Microsoft är inbyggda Roller i Entra, Azure RBAC, Exchange RBAC och Teams resursspecifika medgivande.