Azure Active Directory v 1.0 uç noktasındaki izinler ve onayPermissions and consent in the Azure Active Directory v1.0 endpoint

Şunlara uygulanır:Applies to:
  • Azure AD v1.0 uç noktasıAzure AD v1.0 endpoint

Azure Active Directory (Azure AD), hem OAuth hem de OpenID Connect (OIDC) akışlarında izinleri yaygın olarak kullanır.Azure Active Directory (Azure AD) makes extensive use of permissions for both OAuth and OpenID Connect (OIDC) flows. Uygulamanız Azure AD'den bir erişim belirteci aldığında, bu belirteç uygulamanızın belirli bir kaynakla ilgili olarak sahip olduğu izinleri açıklayan talepler içerir.When your app receives an access token from Azure AD, the access token will include claims that describe the permissions that your app has in respect to a particular resource.

Kapsamolarak da bilinen izinler, kaynağın yalnızca belirtecin uygulamanın hangi API 'ye ait olduğunu denetlemesi gerektiğinden, kaynak için Yetkilendirmeyi kolaylaştırır.Permissions, also known as scopes, make authorization easy for the resource because the resource only needs to check that the token contains the appropriate permission for whatever API the app is calling.

İzin türleriTypes of permissions

Azure AD iki tür izin tanımlar:Azure AD defines two kinds of permissions:

  • Temsilci izinleri - Oturum açmış kullanıcının olduğu uygulamalar tarafından kullanılır.Delegated permissions - Are used by apps that have a signed-in user present. Bu uygulamalar için, kullanıcı veya yönetici uygulamanın istediği onayları verir ve uygulamaya API çağrıları yaparken oturum açmış kullanıcı adına işlem yapması için temsilci izni verilir.For these apps, either the user or an administrator consents to the permissions that the app requests and the app is delegated permission to act as the signed-in user when making calls to an API. API 'ye bağlı olarak, Kullanıcı API 'ye doğrudan izin vermeyebilir ve bunun yerine bir yöneticinin "yönetici onayı" sağlaması gerekir.Depending on the API, the user may not be able to consent to the API directly and would instead require an administrator to provide "admin consent".
  • Uygulama izinleri - Oturum açmış kullanıcı olmadan çalıştırılan uygulamalar tarafından kullanılır; örneğin, arka plan hizmetleri veya daemon programları olarak çalıştırılan uygulamalar böyledir.Application permissions - Are used by apps that run without a signed-in user present; for example, apps that run as background services or daemons. Uygulama izinleri, genellikle güçlü olduklarından ve Kullanıcı sınırları genelinde verilere veya başka türlü yöneticilerle kısıtlanabilecek verilere erişime izin verecek şekilde yalnızca yöneticiler tarafından yapılabilir.Application permissions can only be consented to by administrators because they are typically powerful and allow access to data across user-boundaries, or data that would otherwise be restricted to administrators. Kaynak uygulamanın sahibi olarak tanımlanan kullanıcılar (yani, izinleri yayımlayan API), sahip oldukları API 'Ler için uygulama izinleri vermek için de izin verilir.Users who are defined as owners of the resource application (i.e. the API which publishes the permissions) are also allowed to grant application permissions for the APIs they own.

Etkili izinler, uygulamanızın API istekleri yaparken sahip olacağı izinlerdir.Effective permissions are the permissions that your app will have when making requests to an API.

  • Temsilci izinleri için, uygulamanızın etkili izinleri uygulamaya verilmiş olan (onay yoluyla) temsilci izinleriyle o anda oturum açmış olan kullanıcının ayrıcalıklarının en düşük ayrıcalıklı kesişimi olacaktır.For delegated permissions, the effective permissions of your app will be the least privileged intersection of the delegated permissions the app has been granted (through consent) and the privileges of the currently signed-in user. Uygulamanızın ayrıcalıkları hiçbir zaman oturum açmış kullanıcının ayrıcalıklarından fazla olamaz.Your app can never have more privileges than the signed-in user. Kuruluşların içinde, oturum açmış kullanıcının ayrıcalıkları ilkeyle ya da bir veya birden çok yönetici rolü üyeliğiyle belirlenebilir.Within organizations, the privileges of the signed-in user may be determined by policy or by membership in one or more administrator roles. Hangi Yönetici rollerinin temsilci izinleri onaylamasına izin verebileceğini öğrenmek için bkz. Azure AD 'de yönetici rolü izinleri.To learn which administrator roles can consent to delegated permissions, see Administrator role permissions in Azure AD. Örneğin, Microsoft Graph'te uygulamanıza User.ReadWrite.All temsilci izni verildiğini varsayalım.For example, assume your app has been granted the User.ReadWrite.All delegated permission in Microsoft Graph. Adından da anlaşıldığı gibi bu izin uygulamanıza kuruluştaki her kullanıcının profilini okuma ve güncelleştirme izni verir.This permission nominally grants your app permission to read and update the profile of every user in an organization. Oturum açmış kullanıcının bir genel yönetici olması durumunda, uygulamanız kuruluştaki her kullanıcının profilini güncelleştirebilir.If the signed-in user is a global administrator, your app will be able to update the profile of every user in the organization. Öte yandan oturum açmış kullanıcı bir yönetici rolünde değilse, uygulamanız yalnızca oturum açmış kullanıcının profilini güncelleştirebilir.However, if the signed-in user is not in an administrator role, your app will be able to update only the profile of the signed-in user. Kuruluştaki diğer kullanıcıların profillerini güncelleştiremez çünkü adına çalışma iznine sahip olduğu kullanıcı söz konusu ayrıcalıklara sahip değildir.It will not be able to update the profiles of other users in the organization because the user that it has permission to act on behalf of does not have those privileges.
  • Uygulama izinleri için, uygulamanızın etkili izinleri izin tarafından belirtilen tüm ayrıcalık düzeylerini kapsar.For application permissions, the effective permissions of your app are the full level of privileges implied by the permission. Örneğin, User.ReadWrite.All uygulama iznine sahip bir uygulama kuruluştaki her kullanıcının profilini güncelleştirebilir.For example, an app that has the User.ReadWrite.All application permission can update the profile of every user in the organization.

İzin öznitelikleriPermission attributes

Azure AD'deki izinlerin bir dizi özelliği vardır ve bu özellikler kullanıcıların, yöneticilerin veya uygulama geliştiricilerin iznin ne erişimi verdiği konusunda bilinçli kararlar almasına yardımcı olur.Permissions in Azure AD have a number of properties that help users, administrators, or app developers make informed decisions about what the permission grants access to.

Not

Azure portalını veya PowerShell'i kullanarak Azure AD Uygulaması veya Hizmet Sorumlusunun kullanıma sunduğu izinleri görüntüleyebilirsiniz.You can view the permissions that an Azure AD Application or Service Principal exposes using the Azure portal, or PowerShell. Microsoft Graph tarafından kullanıma sunulan izinleri görüntülemek için bu betiği deneyin.Try this script to view the permissions exposed by Microsoft Graph.

Connect-AzureAD

# Get OAuth2 Permissions/delegated permissions
(Get-AzureADServicePrincipal -filter "DisplayName eq 'Microsoft Graph'").OAuth2Permissions

# Get App roles/application permissions
(Get-AzureADServicePrincipal -filter "DisplayName eq 'Microsoft Graph'").AppRoles
Özellik adıProperty name AçıklamaDescription ÖrnekExample
ID Bu izni benzersiz olarak tanımlayan GUID değeridir.Is a GUID value that uniquely identifies this permission. 570282fd-fa5c-430d-a7fd-fc8dc98a9dca570282fd-fa5c-430d-a7fd-fc8dc98a9dca
IsEnabled Bu iznin kullanılabilir olup olmadığını gösterir.Indicates whether this permission is available for use. doğrutrue
Type Bu iznin kullanıcı onayı veya yönetici onayı gerektirip gerektirmediğini gösterir.Indicates whether this permission requires user consent or admin consent. KullanıcıUser
AdminConsentDescription Yönetici onayı deneyimleri sırasında yöneticilere gösterilen açıklamadırIs a description that's shown to administrators during the admin consent experiences Uygulamanın kullanıcı posta kutularındaki e-postayı okumasına izin verir.Allows the app to read email in user mailboxes.
AdminConsentDisplayName Yönetici onayı deneyimi sırasında yöneticilere gösterilen kolay addır.Is the friendly name that's shown to administrators during the admin consent experience. Kullanıcı postasını okumaRead user mail
UserConsentDescription Kullanıcı onayı deneyimi sırasında kullanıcılara gösterilen açıklamadır.Is a description that's shown to users during a user consent experience. Uygulamanın, posta kutunuzdaki e-postalarınızı okumasına izin verir.Allows the app to read email in your mailbox.
UserConsentDisplayName Kullanıcı onayı deneyimi sırasında kullanıcılara gösterilen kolay addır.Is the friendly name that's shown to users during a user consent experience. Postalarınızı okumaRead your mail
Value OAuth 2.0 yetkilendirme akışları sırasında izni tanımlamak için kullanılan dizedir.Is the string that's used to identify the permission during OAuth 2.0 authorize flows. Value, tam izin adı oluşturmak için Uygulama Kimliği URI dizesiyle birleştirilebilir.Value may also be combined with the App ID URI string in order to form a fully qualified permission name. Mail.Read

Azure AD'deki uygulamalar gerekli kaynaklara veya API'lere erişim kazanmak için onaya bağımlıdır.Applications in Azure AD rely on consent in order to gain access to necessary resources or APIs. Uygulamanızın başarılı olabilmesi için tanıyor olması gereken çeşitli onay türleri vardır.There are a number of kinds of consent that your app may need to know about in order to be successful. İzinleri tanımlıyorsanız, kullanıcıların uygulamanıza veya API'nize nasıl erişim kazanacağını da anlamalısınız.If you are defining permissions, you will also need to understand how your users will gain access to your app or API.

  • Statik kullanıcı onayı - Uygulamanızın etkileşimli çalışmak istediği kaynağı belirttiğinizde OAuth 2.0 yetkilendirme akışı sırasında otomatik olarak gerçekleşir.Static user consent - Occurs automatically during the OAuth 2.0 authorize flow when you specify the resource that your app wants to interact with. Statik kullanıcı onayı senaryosunda, uygulamanızın gereken tüm izinleri Azure portalındaki uygulama yapılandırmasında zaten belirtmiş olması gerekir.In the static user consent scenario, your app must have already specified all the permissions it needs in the app's configuration in the Azure portal. Kullanıcı (veya uygun olduğunda yönetici) bu uygulamaya onay vermezse, Azure AD kullanıcının şu anda onay vermesini ister.If the user (or administrator, as appropriate) has not granted consent for this app, then Azure AD will prompt the user to provide consent at this time.

    Statik bir API kümesine erişim isteyen bir Azure AD uygulamasını kaydetme hakkında daha fazla bilgi edinin.Learn more about registering an Azure AD app that requests access to a static set of APIs.

  • Dinamik kullanıcı onayı - v2 Azure AD uygulama modelinin bir özelliğidir.Dynamic user consent - Is a feature of the v2 Azure AD app model. Bu senaryoda, uygulamanız v2 uygulamaları için OAuth 2.0 yetkilendirme akışı içinde ihtiyacı olan bir dizi izin ister.In this scenario, your app requests a set of permissions that it needs in the OAuth 2.0 authorize flow for v2 apps. Kullanıcı henüz onaylamadıysa, bu aşamada onaylaması istenir.If the user has not consented already, they will be prompted to consent at this time. Dinamik onay hakkında daha fazla bilgi edinin.Learn more about dynamic consent.

    Önemli

    Dinamik onay kullanışlı olabilir ama yönetici onayı gerektiren izinlerde çok zorluk çıkarabilir çünkü yönetici onayı deneyimi, onay zamanında söz konusu izinleri bilmiyor olacaktır.Dynamic consent can be convenient, but presents a big challenge for permissions that require admin consent, since the admin consent experience doesn't know about those permissions at consent time. Yönetici ayrıcalıklı izinlerine ihtiyacınız varsa veya uygulamanız dinamik onay kullanıyorsa, tüm izinleri Azure portal (yalnızca yönetici onayı gerektiren izinlerin alt kümesi değil) kaydetmeniz gerekir.If you require admin privileged permissions or if your app uses dynamic consent, you must register all of the permissions in the Azure portal (not just the subset of permissions that require admin consent). Bu, kiracı yöneticilerinin tüm kullanıcıları adına onay vermesini sağlar.This enables tenant admins to consent on behalf of all their users.

  • Yönetici onayı - Uygulamanızın bazı yüksek ayrıcalıklı izinlere erişmeye ihtiyacı olması durumunda gereklidir.Admin consent - Is required when your app needs access to certain high-privilege permissions. Yönetici onayı, uygulamalara veya kullanıcılara kuruluşunuzun yüksek ayrıcalıklı verilerine erişme yetkisi verilmeden önce yöneticilerin bazı ek denetimler yapabilmesini sağlar.Admin consent ensures that administrators have some additional controls before authorizing apps or users to access highly privileged data from the organization. Yönetici onayı verme hakkında daha fazla bilgi edinin.Learn more about how to grant admin consent.

En iyi uygulamalarBest practices

İstemci en iyi uygulamalarıClient best practices

  • Yalnızca uygulamanızın ihtiyacı olan izinleri isteyin.Only request for permissions that your app needs. Aşırı fazla izinleri olan uygulamaların güvenliği aşıldığında, kullanıcı verilerini açığa çıkarma riski doğar.Apps with too many permissions are at risk of exposing user data if they are compromised.
  • Uygulamanızın desteklediği senaryoya göre temsilci izinleri ve uygulama izinleri arasında seçim yapın.Choose between delegated permissions and application permissions based on the scenario that your app supports.
    • Kullanıcı adına çağrı yapılıyorsa her zaman temsilci izinlerini kullanın.Always use delegated permissions if the call is being made on behalf of a user.
    • Uygulama izinlerini yalnızca uygulama etkileşimli değilse ve herhangi bir kullanıcının adına çağrı yapmıyorsa kullanın.Only use application permissions if the app is non-interactive and not making calls on behalf of any specific user. Uygulama izinleri yüksek ayrıcalıklara sahiptir ve yalnızca gerçekten gerekli olduğunda kullanılmalıdır.Application permissions are highly privileged and should only be used when absolutely necessary.
  • v2.0 uç noktasını temel alan bir uygulama kullandığınızda, yönetici onayı gibi senaryoların doğru şekilde çalışması için statik izinleri (uygulama kaydınızda belirtilenler) çalışma zamanında istenen dinamik izinlerin (kodda belirtilen ve yetkilendirme isteğinizde sorgu parametresi olarak gönderilen) üst kümesi olarak belirleyin.When using an app based on the v2.0 endpoint, always set the static permissions (those specified in your application registration) to be the superset of the dynamic permissions you request at runtime (those specified in code and sent as query parameters in your authorize request) so that scenarios like admin consent works correctly.

Kaynak/API en iyi yöntemleriResource/API best practices

  • API'leri kullanıma sunan kaynaklar, korudukları verilere veya eylemlere özgü izinler tanımlamalıdır.Resources that expose APIs should define permissions that are specific to the data or actions that they are protecting. Bu en iyi yöntemin uygulanması, istemcilerin ihtiyaçları olmayan verilere erişmemesini ve kullanıcıların hangi verilere onay verdikleri konusunda bilgi sahibi olmasını sağlamaya yardımcı olur.Following this best practice helps to ensure that clients do not end up with permission to access data that they do not need and that users are well informed about what data they are consenting to.
  • Kaynaklar Read ve ReadWrite izinlerini ayrı ayrı ve açıkça tanımlamalıdır.Resources should explicitly define Read and ReadWrite permissions separately.
  • Kaynaklar, kullanıcı sınırlarının ötesinde veri erişimine olanak tanıyan tüm izinleri Admin izinleri olarak işaretlemelidir.Resources should mark any permissions that allow access to data across user boundaries as Admin permissions.
  • Kaynakların Subject.Permission[.Modifier] adlandırma modelini kullanması gerekir:Resources should follow the naming pattern Subject.Permission[.Modifier], where:
    • Subject, kullanılabilir veri türüne karşılık gelirSubject corresponds with the type of data that is available

    • Permission, kullanıcının bu verileri üzerinde işlem yapması için gereken eyleme karşılık gelirPermission corresponds to the action that a user may take upon that data

    • Modifier, farklı bir iznin özelleştirmelerini anlatmak için isteğe bağlı olarak kullanılırModifier is used optionally to describe specializations of another permission

      Örnek:For example:

    • Mail.Read - Kullanıcıların postayı okumasına izin verir.Mail.Read - Allows users to read mail.

    • Mail.ReadWrite - Kullanıcıların postayı yazmasına veya okumasına izin verir.Mail.ReadWrite - Allows users to read or write mail.

    • Mail.ReadWrite.All - Yöneticinin veya kullanıcının kuruluştaki tüm postaya erişmesine izin verir.Mail.ReadWrite.All - Allows an administrator or user to access all mail in the organization.