Microsoft kimlik platformu izinler ve onay

Microsoft kimlik platformu ile tümleşen uygulamalar, kullanıcılara ve yöneticilere verilere nasıl erişilebileceği üzerinde denetim sağlayan bir yetkilendirme modeli izler. yetkilendirme modelinin uygulanması Microsoft kimlik platformu güncelleştirildi. bir uygulamanın Microsoft kimlik platformu nasıl etkileşim kurması gerektiğini değiştirir. Bu makalede kapsamlar, izinler ve onay dahil olmak üzere bu yetkilendirme modelinin temel kavramları ele alınmaktadır.

Kapsamlar ve izinler

Microsoft kimlik platformu, OAuth 2,0 yetkilendirme protokolünü uygular. OAuth 2,0, bir üçüncü taraf uygulamanın bir kullanıcı adına Web 'de barındırılan kaynaklara erişebileceği bir yöntemdir. Microsoft kimlik platformu ile tümleştirilen web 'de barındırılan herhangi bir kaynağın bir kaynak tanımlayıcısı veya uygulama kimliği urı 'si vardır.

Aşağıda, Microsoft 'un web 'de barındırılan kaynakların bazı örnekleri verilmiştir:

• Microsoft Graph:https://graph.microsoft.com
• Microsoft 365 Posta API 'SI:https://outlook.office.com
• Azure Key Vault: https://vault.azure.net

aynı, Microsoft kimlik platformu ile tümleştirilmiş tüm üçüncü taraf kaynakları için de geçerlidir. Bu kaynakların herhangi biri aynı zamanda söz konusu kaynağın işlevselliğini daha küçük parçalara bölmek için kullanılabilecek bir izinler kümesi tanımlayabilir. örnek olarak Microsoft Graph , diğerleri arasında aşağıdaki görevleri yapmak için tanımlı izinlere sahiptir:

• Kullanıcının takvimini oku
• Kullanıcının takvimine yazma
• Kullanıcı olarak posta gönder

Bu izin tanımları türleri nedeniyle, kaynağın verileri üzerinde ayrıntılı denetimi ve API işlevinin sunulma şeklini vardır. Üçüncü taraf bir uygulama, kullanıcıların ve yöneticilerin bu izinleri talep edebilir ve uygulamanın verilere erişebilmeleri veya Kullanıcı adına işlem yapması için isteği onaylaması gerekir.

Bir kaynağın işlevselliği küçük izin kümelerine öbekli olduğunda, üçüncü taraf uygulamalar yalnızca kendi işlevlerini gerçekleştirmeleri için ihtiyaç duydukları izinleri istemek üzere oluşturulabilir. Kullanıcılar ve Yöneticiler, uygulamanın hangi verileri erişebileceği hakkında bilgi alabilir. Ayrıca, uygulamanın kötü amaçlı bir amaç ile davranmadığından daha emin olabilirler. Geliştiriciler, yalnızca uygulamalarının çalışması için ihtiyaç duydukları izinleri isteyen en az ayrıcalık ilkesine göre her zaman bilmelidir.

OAuth 2,0 ' de, bu izin kümesi türleri kapsamlar olarak adlandırılır. Bunlar da genellikle izinler olarak adlandırılır. Microsoft kimlik platformu, bir izin dize değeri olarak temsil edilir. Bir uygulama, sorgu parametresinde izni belirterek ihtiyaç duyacağı izinleri ister scope . kimlik platformu, iyi tanımlanmış birkaç openıd Bağlan kapsamını ve kaynak tabanlı izinleri destekler (her izin, izin değeri kaynağın tanımlayıcısına veya uygulama kimliği urı 'sine eklenerek belirtilir). Örneğin, izin dizesi https://graph.microsoft.com/Calendars.Read Microsoft Graph kullanıcı takvimlerini okumak için izin istemek üzere kullanılır.

bu izinleri en yaygın olarak, Microsoft kimlik platformu yetkilendirme uç noktasına yönelik isteklerindeki kapsamları belirterek ister. Ancak, bazı yüksek ayrıcalıklı izinler yalnızca yönetici onayı üzerinden verilebilir. Yönetici onay uç noktasıkullanılarak talep edilebilir veya verilebilir. Daha fazla bilgi edinmek için okumaya devam edin.

Microsoft Identity platformu yetkilendirme, belirteç veya onay uç noktalarına yönelik isteklerde, kaynak tanımlayıcısı kapsam parametresinde atlanırsa kaynağın Microsoft Graph olduğu varsayılır. Örneğin scope=User.Read ile https://graph.microsoft.com/User.Read eşdeğerdir.

İzin türleri

Microsoft kimlik platformu iki tür izni destekler: temsilci izinleri ve uygulama izinleri.

• Temsilci izinleri , oturum açmış bir Kullanıcı bulunan uygulamalar tarafından kullanılır. Bu uygulamalar için, Kullanıcı ya da yönetici, uygulamanın istediği izinleri onaylar. Uygulama, hedef kaynağa çağrılar yaptığında oturum açmış bir kullanıcı olarak görev yapmak için izin verildi.

  Bazı Temsilcili izinler, yönetici olmayanlar tarafından yapılabilir. Ancak bazı yüksek ayrıcalıklı izinler yönetici onayıgerektirir. Hangi Yönetici rollerinin temsilci izinleri onaylamasına izin verebileceğini öğrenmek için Azure Active Directory (Azure AD) Içinde yönetici rolü izinleribölümüne bakın.

• Uygulama izinleri , oturum açmış bir kullanıcı olmadan çalışan uygulamalar tarafından kullanılır; Örneğin, arka plan hizmetleri veya Daemon 'ları olarak çalışan uygulamalar. Yalnızca bir yönetici, uygulama izinlerini kabul edebilir .

Etkili izinler , uygulamanızın hedef kaynağa istek yaptığında sahip olduğu izinlerdir. Uygulamanızın verdiği temsilci izinleri ve uygulama izinleri arasındaki farkın ve hedef kaynağa çağrı yaptığında uygulamanızın verdiği etkin izinlerin anlaşılması önemlidir.

• Temsilci izinleri için uygulamanızın etkili izinleri , uygulamaya atanan izinlerin en az ayrıcalıklı kesişimine (izin olarak) ve şu anda oturum açmış kullanıcının ayrıcalıklarına sahiptir. Uygulamanızın ayrıcalıkları hiçbir zaman oturum açmış kullanıcının ayrıcalıklarından fazla olamaz.

  Kuruluşlar içinde, oturum açmış kullanıcının ayrıcalıkları ilke tarafından veya bir veya daha fazla yönetici rolünde üyelikle belirlenebilir. Hangi Yönetici rollerinin temsilci izinleri onaylamasına izin verebileceğini öğrenmek için bkz. Azure AD 'de yönetici rolü izinleri.

  Örneğin, uygulamanıza User. ReadWrite. All temsilcisi izni verildiğini varsayalım. 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. Oturum açmış kullanıcı genel yöneticidir, uygulamanız kuruluştaki her kullanıcının profilini güncelleştirebilir. Ancak, oturum açmış kullanıcının yönetici rolü yoksa, uygulamanız yalnızca oturum açan kullanıcının profilini güncelleştirebilir. Adına işlem yapması gereken Kullanıcı bu ayrıcalıklara sahip olmadığından kuruluştaki diğer kullanıcıların profillerini güncelleştiremez.

• Uygulama izinleri için uygulamanızın etkili izinleri , izin tarafından ima edilen ayrıcalıkların tam düzeyidir. Örneğin, User. ReadWrite olan bir uygulama. tüm uygulama izinleri, kuruluştaki her kullanıcının profilini güncelleştirebilir.

openıd Bağlan kapsamları

openıd Bağlan Microsoft kimlik platformu uygulamasının, Microsoft Graph:,,, ve ' de barındırılan bazı iyi tanımlanmış kapsamları vardır openid email profile offline_access . addressve phone openıd Bağlan kapsamları desteklenmez.

openıd Bağlan kapsamlarını ve bir belirteci istemeniz durumunda, userınfo uç noktasınıçağırmak için bir belirteç alırsınız.

OpenID

bir uygulama openıd Bağlankullanarak oturum açarsa, kapsam istemesi gerekir openid . openidKapsam, oturum açma izniniz olarak iş hesabı onayı sayfasında görünür. Kişisel Microsoft hesabı izni sayfasında, profilinizi görüntüleme ve Microsoft hesabı izniniz kullanılarak uygulamalara ve hizmetlere bağlanma gibi görünür.

Bu izni kullanarak bir uygulama, talep biçiminde kullanıcı için benzersiz bir tanımlayıcı alabilir sub . Bu izin, uygulamanın UserInfo uç noktasına erişimini de sağlar. openidkapsam, kimlik belirteçleri almak için Microsoft kimlik platformu belirteç uç noktasında kullanılabilir. Uygulama bu belirteçleri kimlik doğrulaması için kullanabilir.

e-posta

emailKapsam openid ve diğer kapsamlarla birlikte kullanılabilir. Uygulama, kullanıcının birincil e-posta adresine talep biçiminde erişim sağlar email .

emailTalep, yalnızca bir e-posta adresi kullanıcı hesabıyla ilişkiliyse, her zaman durum olmayan bir belirtece dahil edilir. Uygulamanız email kapsamı kullanıyorsa, uygulamanın belirteçte talep bulunmayan bir servis talebini işleyebilmesi gerekir email .

profil

profileKapsam, openid kapsam ve diğer tüm kapsamlar ile birlikte kullanılabilir. Uygulamanın kullanıcı hakkındaki büyük miktarda bilgiye erişmesini sağlar. Erişebileceği bilgiler, kullanıcının verilen adı, soyadı, tercih edilen Kullanıcı adı ve nesne KIMLIĞINI içerir, ancak bunlarla sınırlı değildir.

profileBelirli bir kullanıcının parametresinde bulunan taleplerin tüm listesi için id_tokens , id_tokens başvuruyabakın.

offline_access

offline_access Kapsam , uygulamanızın kullanıcı adına uzun bir süre boyunca kaynaklara erişmesini sağlar. Onay sayfasında bu kapsam, izin erişimi verdiğiniz verilere erişim sağlama olarak görünür.

kullanıcı kapsamı onayladığında offline_access , uygulamanız Microsoft kimlik platformu belirteç uç noktasından yenileme belirteçleri alabilir. Yenileme belirteçleri uzun süreli. Uygulamanız, eski kullanım süreleri dolana kadar yeni erişim belirteçleri alabilir.

Microsoft kimlik platformu (v 2.0 uç noktasına yapılan istekler) üzerinde, uygulamanızın offline_access yenileme belirteçleri alması için açıkça kapsama istemesi gerekir. Bu nedenle, OAuth 2,0 yetkilendirme kodu akışındabir yetkilendirme kodu kullandığınızda uç noktadan yalnızca bir erişim belirteci alacaksınız /token .

Erişim belirteci kısa bir süre için geçerlidir. Genellikle bir saat içinde sona erer. Bu noktada, uygulamanızın /authorize Yeni bir yetkilendirme kodu almak için kullanıcıyı uç noktaya yeniden yönlendirmesi gerekir. Bu yeniden yönlendirme sırasında, uygulamanın türüne bağlı olarak, kullanıcının kimlik bilgilerini yeniden girmesi veya izinleri yeniden onaylaması gerekebilir.

yenileme belirteçleri alma ve kullanma hakkında daha fazla bilgi için Microsoft kimlik platformu protokol başvurusunabakın.

Onay türleri

Uygulama Microsoft kimlik platformu, gerekli kaynaklara veya API'lere erişim elde etmek için onay kullanır. Uygulamanızın başarılı olabilmesi için tanıyor olması gereken çeşitli onay türleri vardır. İ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.

Statik kullanıcı onayı

Statik kullanıcı onayı senaryosunda, uygulamanın yapılandırmasında gereken tüm izinleri uygulamanın Azure portal. Kullanıcı (veya yönetici uygun şekilde) bu uygulama için onay vermezse, Microsoft kimlik platformu kullanıcıdan şu anda onay sağlamasını ister.

Statik izinler, yöneticilerin kuruluşta tüm kullanıcılar adına onaylar atamasını da sağlar.

Uygulamada tanımlanan uygulamanın statik izinleri Azure portal ve basit tutmakla birlikte geliştiriciler için bazı olası sorunlar sunar:

• Uygulamanın, kullanıcının ilk oturum açma sırasında ihtiyaç sahip olduğu tüm izinleri isteğinde olması gerekir. Bu, son kullanıcıların ilk oturum açma sırasında uygulama erişimini onaylamasını öneren uzun bir izin listesine yol açabilirsiniz.

• Uygulamanın, erişenin tüm kaynakları zamanından önce biliyor olması gerekir. Rastgele sayıdaki kaynaklara erişen uygulamalar oluşturmak zordur.

Artımlı ve dinamik kullanıcı onayı

Uygulama Microsoft kimlik platformu ile, uygulama kayıt bilgisinde tanımlanan statik izinleri yoksayabilirsiniz ve bunun Azure portal artımlı olarak izinler isteğinde bulundurabilirsiniz. Müşteri ek uygulama özelliklerini kullandığı için en az bir izin kümesi için peşin istekte bulundurabilirsiniz ve zaman içinde daha fazla istekte bulundurabilirsiniz. Bunu yapmak için, uygulama kayıt bilgisinde önceden tanımlamanıza gerek kalmadan, erişim belirteci isteğinde yeni kapsamları parametresine dahil etmek için istediğiniz zaman uygulamanıza gereken scope kapsamları belirtebilirsiniz. Kullanıcı henüz i isteğine eklenen yeni kapsamlara onay vermezse, yalnızca yeni izinleri onaylar. Artımlı veya dinamik onay, uygulama izinlerine değil yalnızca temsilci izinlerine uygulanır.

Bir uygulamanın parametresi aracılığıyla dinamik olarak izin isteğinde sınanmalarına scope izin verme, geliştiricilerin kullanıcı deneyimi üzerinde tam denetime sahip olduğunu sağlar. Ayrıca, onay deneyiminizi ön yükleme ve tek bir ilk yetkilendirme isteğinde tüm izinleri isteme. Uygulamanız çok sayıda izin gerektiriyorsa, zaman içinde uygulamanın belirli özelliklerini kullanmayı deneyen kullanıcıdan bu izinleri artımlı olarak topabilirsiniz.

Yönetici onayı

Uygulamanıza belirli yüksek ayrıcalıklı izinlere erişmesi gerektiğinde yönetici onayı gerekir. 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.

Bir kuruluş adına yapılan yönetici onayı yine de uygulama için kayıtlı statik izinler gerektirir. Kuruluşun tamamı adına onay vermek için bir yöneticiye ihtiyacınız varsa, uygulama kayıt portalında uygulamalar için bu izinleri ayarlayın. Bu, kuruluş yöneticisinin uygulamayı ayarlaması için gereken döngüleri azaltır.

Bireysel kullanıcı onayı isteği

OpenID Bağlan veya OAuth 2.0 yetkilendirme isteğinde, bir uygulama sorgu parametresini kullanarak ihtiyacı olan scope izinleri ister. Örneğin, bir kullanıcı uygulamada oturum açsa, uygulama aşağıdaki örnekte olduğu gibi bir istek gönderir. (Okunaklılık için satır sonları eklenir.)

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=
https%3A%2F%2Fgraph.microsoft.com%2Fcalendars.read%20
https%3A%2F%2Fgraph.microsoft.com%2Fmail.send
&state=12345

parametresi, scope uygulamanın istekte olduğu temsilci izinlerinin boşlukla ayrılmış bir listesidir. Her izin, izin değeri kaynağın tanımlayıcısına (uygulama kimliği URI'sı) ekilerek belirtilmiştir. İstek örneğinde, uygulamanın kullanıcının takvimini okuma ve kullanıcı olarak posta gönderme iznine sahip olması gerekir.

Kullanıcı kimlik bilgilerini girdikten sonra, kullanıcı Microsoft kimlik platformu eşleşen bir kullanıcı onayı kaydını denetler. Kullanıcı geçmişte istenen izinlerden herhangi birini kabul etmemişse ve yönetici bu izinlere kuruluşun tamamı adına onay vermezse Microsoft kimlik platformu kullanıcıdan istenen izinleri atamasını isterse.

Şu anda ("Verilere erişim iznini verilmiş olan verilere erişimi sürdürme") ve ("Oturum açma ve profilinizi okuma") izni, bir uygulamanın ilk onayına otomatik olarak offline_access user.read eklenir. Bu izinler genellikle uygun uygulama işlevselliği için gereklidir. bu offline_access izin, uygulamanın yerel uygulamalar ve web uygulamaları için kritik öneme sahip olan yenileme belirteçlerine erişmesini sağlar. İzin, user.read talepe erişim sub verir. İstemcinin veya uygulamanın zaman içinde kullanıcıyı doğru şekilde tanımlaması ve ilkel kullanıcı bilgilerine erişmesini sağlar.

Kullanıcı izin isteğini onaylarsa onay kaydedilir. Kullanıcının daha sonra uygulamada oturum a açması için yeniden onay onayına sahip olması gerekmektedir.

Kiracının tamamı için onay isteği

Bir kuruluş bir uygulama için lisans veya abonelik satın aldı mı, genellikle uygulamayı kuruluşun tüm üyeleri tarafından kullanmak üzere proaktif olarak ayarlamak ister. Bu sürecin bir parçası olarak, bir yönetici kiracıda herhangi bir kullanıcı adına işlem yapmak için uygulama için onay veebilir. Yönetici kiracının tamamı için onay verdiyseniz, kuruluşun kullanıcıları uygulama için bir onay sayfası görmüyordur.

Bir kuruluş adına yönetici onayı yapılması, uygulama için statik izinlerin kayıtlı olması gerekir. Kuruluşun tamamı adına onay vermek için bir yöneticiye ihtiyacınız varsa, uygulama kayıt portalında uygulamalar için bu izinleri ayarlayın.

Bir kiracıda tüm kullanıcılar için temsilci izinleri için onay isteğinde etmek üzere, uygulamanız yönetici onayı uç noktasını kullanabilir.

Ayrıca, uygulamaların uygulama izinleri isteği için yönetici onayı uç noktasını kullanmaları gerekir.

Yönetici tarafından kısıtlanmış izinler

Microsoft kaynaklarında bazı yüksek ayrıcalıklı izinler, yönetici tarafından kısıtlanmış olarak ayarlanabilir. Bu izin türlerine bazı örnekler aşağıda verilmiştir:

• kullanarak tüm kullanıcının tam profillerini okuma User.Read.All
• kullanarak kuruluşun dizinine veri yazma Directory.ReadWrite.All
• kullanarak kuruluşun dizininde tüm grupları okuma Groups.Read.All

Tüketici kullanıcı bir uygulamaya bu tür veriler için erişim izni verse de, kuruluş kullanıcıları aynı hassas şirket verileri kümesine erişim izni ve vermez. Uygulamanız bir kuruluş kullanıcıdan bu izinlerden birini talep ediyorsa, kullanıcı, uygulama izinlerine onay yetkisi olmadığını söyleyen bir hata iletisi alır.

Uygulamanıza yöneticiyle kısıtlanmış izinler için kapsamlar gerekiyorsa, kuruluşun yöneticisinin bu kapsamlara kuruluş kullanıcıları adına onay ataması gerekir. Kullanıcıların izin veremezler için onay isteğinde bulunan istemleri görüntülemelerini önlemek için, uygulamanız yönetici onayı uç noktasını kullanabilir. Yönetici onayı uç noktası bir sonraki bölümde ele alınyacaktır.

Uygulama yüksek ayrıcalıklı temsilci izinleri talep ediyorsa ve bir yönetici bu izinleri yönetici onay uç noktası üzerinden verdiyseniz, kiracıda tüm kullanıcılar için onay ve edilir.

Uygulama uygulama izinleri talep ediyorsa ve bir yönetici bu izinleri yönetici onay uç noktası üzerinden sağlarsa, bu izin belirli bir kullanıcı adına yapılmaz. Bunun yerine, istemci uygulamasına doğrudan izinler verildi. Bu izin türleri yalnızca arka planda çalıştıran daemon hizmetleri ve diğer yorumsız uygulamalar tarafından kullanılır.

Yönetici onayı uç noktasını kullanma

Yönetici onayı vermek için yönetici onay uç noktasını kullandıktan sonra, tamamsınız. Kullanıcıların başka bir işlem yapmak zorunda değildir. Yönetici onayı verildikten sonra, kullanıcılar tipik bir kimlik doğrulama akışı aracılığıyla erişim belirteci elde eder. Sonuçta elde edilen erişim belirteci onay verilen izinlere sahip olur.

Genel Yönetici, uygulamanızı kullandığında ve yetkilendirme uç noktasına Microsoft kimlik platformu kullanıcının rolünü algılar. Genel Yöneticinin, isteğiniz izinler için kiracının tamamı adına onay almak istediğini sorar. Bunun yerine, bir yöneticiden kiracının tamamı adına proaktif olarak izin verilmesini talep etmek için ayrılmış bir yönetici onayı uç noktası kullanabilirsiniz. Bu uç nokta, uygulama izinleri isteği için de gereklidir. Yetkilendirme uç noktası kullanılarak uygulama izinleri talep edilebilir.

Bu adımları takip ederseniz, uygulamanız yönetici tarafından kısıtlanmış kapsamlar dahil olmak üzere bir kiracıda yer alan tüm kullanıcılar için izin isteğinde olabilir. Bu işlem yüksek ayrıcalıktır. Yalnızca senaryo için gerekirse işlemi kullanın.

Adımları uygulayan bir kod örneği görmek için, GitHub'da yönetici tarafından kısıtlanmış kapsamlar örneğine bakın.

Uygulama kayıt portalında izinleri talep edin

Uygulama kayıt portalında uygulamalar, hem temsilci izinleri hem de uygulama izinleri dahil olmak üzere gerekli izinleri listelemektedir. Bu kurulum kapsamın ve uygulamanın /.default Yönetici onayı Azure portal izin ver seçeneğinin kullanımına izin verir.

Genel olarak, izinler belirli bir uygulama için statik olarak tanımlanmalıdır. Bunlar, uygulamanın dinamik olarak veya artımlı olarak isteğine neden olacak izinlerin üst kümesidir.

Bir uygulama için statik olarak istenen izinler listesini yapılandırmak için:

1. Azure portal - Uygulama kayıtları deneyiminde uygulamanıza gidin.
2. Bir uygulama seçin veya henüz oluşturmadıysanız bir uygulama oluşturun.
3. Uygulamanın Genel Bakış sayfasındaki Yönet'in altında API İzinleri İzin > ekle'yi seçin.
4. Kullanılabilir API Graph Microsoft Graph'yi seçin. Ardından, uygulamanıza gereken izinleri ekleyin.
5. İzin Ekle'yi seçin.

Önerilen: Kullanıcının uygulamanıza oturum açması

Genellikle, yönetici onayı uç noktasını kullanan bir uygulama derlemek için uygulamanın, yöneticinin uygulama izinlerini onaylandırarak bir sayfa veya görünüme ihtiyacı vardır. Bu sayfa şöyle olabilir:

• Uygulamanın kaydolma akışının bir parçası.
• Uygulama ayarlarının bir parçası.
• Ayrılmış bir "bağlan" akışı.

Çoğu durumda, uygulamanın bu "bağlan" görünümünü yalnızca bir kullanıcı iş veya okul hesabıyla oturum Microsoft hesabı göstermek Microsoft hesabı.

Kullanıcının uygulamanıza oturum açmasını sağlarken, gerekli izinleri onaylamasını istemeden önce yöneticinin ait olduğu kuruluşu tanımlayabilirsiniz. Bu adım kesinlikle gerekli değildir ancak kuruluş kullanıcılarınız için daha sezgisel bir deneyim oluşturmanıza yardımcı olabilir.

Kullanıcının oturum açmasını yapmak için, Microsoft kimlik platformu yönergelerini izleyin.

Dizin yöneticisinden izin isteği

Kuruluş yöneticinizden izin isteğine hazır olurken, kullanıcınızı yönetici onayı uç noktasına Microsoft kimlik platformu yönlendirebilirsiniz.

// Line breaks are for legibility only.
GET https://login.microsoftonline.com/{tenant}/v2.0/adminconsent?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&state=12345
&redirect_uri=http://localhost/myapp/permissions
&scope=
https://graph.microsoft.com/calendars.read
https://graph.microsoft.com/mail.send

Bu noktada Azure AD, isteği tamamlamak için bir kiracı yöneticisinin oturum açmasını gerektirir. Yöneticiden, parametresinde isteğiniz tüm izinleri onaylaması scope istenecek. Statik ( ) değeri /.default kullandıysanız, v1.0 yönetici onayı uç noktası gibi işlev gösterir ve uygulama için gerekli izinlerde bulunan tüm kapsamlar için onay isteğinde bulunur.

Başarılı yanıt

Yönetici, uygulamanıza izinler onaylarsa, başarılı yanıt şöyle olur:

GET http://localhost/myapp/permissions?tenant=a8990e1f-ff32-408a-9f8e-78d3b9139b95&state=state=12345&admin_consent=True

Hata yanıtı

Yönetici, uygulamanıza izinler onaylamazsa başarısız yanıt şöyle olur:

GET http://localhost/myapp/permissions?error=permission_denied&error_description=The+admin+canceled+the+request

Yönetici onayı uç noktasına başarılı bir yanıt verdikten sonra, uygulamanız istenen izinleri elde etti. Ardından, istediğiniz kaynak için bir belirteç isteğide bulundurebilirsiniz.

İzinleri kullanma

Kullanıcı uygulamanıza izin verdikten sonra, uygulamanın kapasitede bir kaynağa erişme iznini temsil eden erişim belirteçleri edinebilirsiniz. Erişim belirteci yalnızca tek bir kaynak için kullanılabilir. Ancak erişim belirteci içinde kodlanmış, bu kaynak için uygulamanıza verilen her izindir. Bir erişim belirteci almak için, uygulama aşağıdaki gibi Microsoft kimlik platformu uç noktasına istekte olabilir:

POST common/oauth2/v2.0/token HTTP/1.1
Host: https://login.microsoftonline.com
Content-Type: application/json

{
    "grant_type": "authorization_code",
    "client_id": "6731de76-14a6-49ae-97bc-6eba6914391e",
    "scope": "https://outlook.office.com/mail.read https://outlook.office.com/mail.send",
    "code": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...",
    "redirect_uri": "https://localhost/myapp",
    "client_secret": "zc53fwe80980293klaj9823"  // NOTE: Only required for web apps
}

Kaynağa yapılan HTTP isteklerinde sonuçta elde edilen erişim belirteci kullanabilirsiniz. Güvenilir bir şekilde kaynağa, uygulamanın belirli bir görevi yapmak için uygun izinlere sahip olduğunu gösterir.

OAuth 2.0 protokolü ve erişim belirteçleri hakkında daha fazla bilgi için bkz. Microsoft kimlik platformu uç nokta protokolü başvurusu.

/.default kapsamı

Kapsamı, uygulamalarınızı /.default v1.0 uç noktası olan uygulama uç noktasına geçirmenize yardımcı Microsoft kimlik platformu kullanabilirsiniz. Kapsam, /.default uygulama kaydında yapılandırılan statik izin listesine başvuran her uygulama için yerleşiktir.

scopedeğeri, https://graph.microsoft.com/.default resource=https://graph.microsoft.com v1.0 uç noktasıyla işlevsel olarak aynıdır. İsteğinde kapsamı belirterek, uygulama kayıt portalında uygulama için seçtiğiniz her Microsoft Graph izninin kapsamlarını içeren bir erişim https://graph.microsoft.com/.default belirteci talep eder. Kapsam, kaynak URI'si ve kullanılarak /.default oluşturulur. Bu nedenle kaynak URI'si https://contosoApp.com ise istenen kapsam şu şekildedir: https://contosoApp.com/.default . Belirteci doğru şekilde talep etmek için ikinci bir eğik çizgi dahil etmek zorunda olduğunuz durumlar için sonda eğik çizgi ile ilgili bölüme bakın.

Kapsam /.default herhangi bir OAuth 2.0 akışında kullanılabilir. Ancak, On-Behalf-Of akışında ve istemci kimlik bilgileri akışında gereklidir. Uygulama izinleri isteği için v2 yönetici onayı uç noktasını kullanırken de buna ihtiyacınız vardır.

İstemciler statik ( ) onay /.default ve dinamik onayı tek bir istekte birleştiremez. Bu scope=https://graph.microsoft.com/.default+mail.read nedenle, kapsam türlerini birleştir olduğundan bir hatayla sonuç verir.

/.default ve onay

Kapsam /.default v1.0 uç nokta davranışını da prompt=consent tetikler. Kaynak ne olursa olsun uygulamanın kayıtlı olduğu tüm izinler için onay isteği gösterir. İsteğin bir parçası olarak dahil edilirse, kapsam istenen kaynağın kapsamlarını /.default içeren bir belirteç döndürür.

Kullanıcı zaten onay verdiği zaman /.default

Kapsam, /.default resource -centric v1.0 uç noktasının davranışıyla işlevsel olarak aynıdır. v1.0 uç noktasının onay davranışını da taşır. Başka bir /.default ifadeyle, yalnızca kullanıcı istemci ile kaynak arasında izin verilmediğinde bir onay istemi tetikler.

Böyle bir onay varsa, döndürülen belirteç kullanıcının bu kaynak için verilen tüm kapsamları içerir. Ancak, hiçbir izin verilmediğinde veya parametre sağlandı ise, istemci uygulamasının kayıtlı olduğu tüm kapsamlar için prompt=consent bir onay istemi gösterilir.

Örnek 1: Kullanıcı veya kiracı yöneticisi izinler verdi

Bu örnekte, kullanıcı veya kiracı yöneticisi istemciye ve Microsoft Graph mail.read user.read izinlerini verdi.

İstemci isteğinde olursa, microsoft için istemci uygulamasının kayıtlı izinlerinin içeriğine bakılmaksızın hiçbir onay scope=https://graph.microsoft.com/.default istemi Graph. Döndürülen belirteç ve kapsamlarını mail.read user.read içerir.

Örnek 2: Kullanıcıya istemci ile kaynak arasında izin verilmedi

Bu örnekte kullanıcı, istemci ile Microsoft Graph. İstemci ve izinleri için user.read contacts.read kaydedilmiştir. Ayrıca, uygulama kapsamına https://vault.azure.net/user_impersonation Azure Key Vault.

İstemci için bir belirteç isteğinda bulunsa, kullanıcı kapsam, kapsam ve etki alanı kapsamları için scope=https://graph.microsoft.com/.default user.read bir onay Key Vault contacts.read user_impersonation görür. Döndürülen belirteç yalnızca ve user.read contacts.read kapsamlarını içerir. Yalnızca Microsoft Graph.

Örnek 3: Kullanıcı onay verdi ve istemci daha fazla kapsam talep ediyor

Bu örnekte, kullanıcı istemci için zaten onay mail.read verdi. İstemci, kapsam için contacts.read kaydedilmiştir.

İstemci kullanarak bir belirteç isteğinda bulunarak ve üzerinden onay isteğite bulunsa, kullanıcı uygulamanın kayded olduğu tüm scope=https://graph.microsoft.com/.default izinler (ve yalnızca) için bir prompt=consent onay sayfası görür. Kapsam contacts.read onay sayfasındadır ancak mail.read değildir. Döndürülen belirteç Microsoft Graph. ve mail.read contacts.read içerir.

İstemci ile /.default kapsamını kullanma

Bazı durumlarda, bir istemci kendi kapsamını /.default isteğinde olabilir. Aşağıdaki örnek bu senaryoyu gösteriyor.

// Line breaks are for legibility only.

GET https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
response_type=token            //Code or a hybrid flow is also possible here
&client_id=9ada6f8a-6d83-41bc-b169-a306c21527a5
&scope=9ada6f8a-6d83-41bc-b169-a306c21527a5/.default
&redirect_uri=https%3A%2F%2Flocalhost
&state=1234

Bu kod örneği, önceki onay açıklamaları senaryoya uygulanıyorsa tüm kayıtlı izinler için /.default bir onay sayfası üretir. Ardından kod, erişim id_token belirteci yerine bir döndürür.

Bu davranış, Azure AD Kimlik Doğrulama Kitaplığı'dan (ADAL) Microsoft Authentication Library'ye (MSAL) hareket eden bazı eski istemcileri barındırıyor. Bu kurulum, istemciyi hedef alan yeni istemciler tarafından Microsoft kimlik platformu.

İstemci kimlik bilgileri akışı ve /.default izni

Bir diğer kullanım alanı da, bir web API'sini çağıran istemci kimlik bilgilerini kullanan bir daemon uygulaması gibi bir yorum olmayan uygulamada uygulama izinleri /.default (veya rolleri) isteğinde etmektir.

Bir web API'si için uygulama izinleri (roller) oluşturmak için bkz. Uygulamanıza uygulama rolleri ekleme.

İstemci uygulamanıza gelen istemci kimlik bilgileri isteklerinin içermesi scope={resource}/.default gerekir. Burada, {resource} uygulamanın çağırmayı amacı olan web API'si yer almaktadır. Tek tek uygulama izinlerini (rolleri) kullanarak istemci kimlik bilgileri isteği verme desteklenmiyor. Bu web API'si için verilen tüm uygulama izinleri (roller) döndürülen erişim belirtecsine dahil edilir.

Uygulama için yönetici onayı vermek de dahil olmak üzere tanımladığınız uygulama izinlerine erişim vermek için bkz. İstemci uygulamasını web API'lerine erişmek üzere yapılandırma.

Sonda eğik çizgi ve /.default

Bazı kaynak URL'leri, örneğin yerine eğik https://contoso.com/ çizgiyle devam https://contoso.com ediyor. Sonda eğik çizgi, belirteç doğrulamasıyla ilgili sorunlara neden olabilir. Sorunlar öncelikli olarak , ( ) için belirteç isten Azure Resource Manager https://management.azure.com/ oluşur. Bu durumda kaynak URI'sinde sonda bir eğik çizgi olması, belirteç istenerek eğik çizginin mevcut olması gerektiğini gösterir. Bu nedenle, ve için bir belirteç https://management.azure.com/ isteğide /.default bulundurarak isteğide bulundurarak (çift eğik https://management.azure.com//.default çizgiye dikkat edersiniz!) gerekir. Genel olarak belirteci doğrularsanız ve belirteci kabul eden API tarafından reddediliyorsa ikinci bir eğik çizgi eklemeyi ve yeniden deneyin.

İzinler ve onay sorunlarını giderme

Sorun giderme adımları için bkz. Bir uygulamaya onay yaparken beklenmeyen hata.

Sonraki adımlar

• Kimlik belirteçleri Microsoft kimlik platformu
• Microsoft kimlik platformu'de belirteçlere erişme