Aracılığıyla paylaş


Neden Microsoft kimlik platformuna (v2.0) güncelleştirmelisiniz?

Yeni bir uygulama geliştirirken, Microsoft kimlik platformu (v2.0) ile Azure Active Directory (v1.0) uç noktaları arasındaki farkları bilmek önemlidir. Bu makale, uç noktalar arasındaki temel farkları ve Microsoft kimlik platformu için bazı mevcut sınırlamaları kapsar.

Kimler oturum açabilir?

v1.0 ve v2.0 uç noktalarıyla oturum açabilen kişiler

  • v1.0 uç noktası, yalnızca iş ve okul hesaplarının uygulamanızda oturum açmasına izin verir (Azure AD)
  • Microsoft kimlik platformu uç noktası, hotmail.com, outlook.com ve msn.com gibi Microsoft Entra kimliğinden ve kişisel Microsoft hesaplarından (MSA) iş ve okul hesaplarının oturum açmasına olanak tanır.
  • Her iki uç nokta da tek kiracılı olarak yapılandırılan uygulamalar veya kiracıya özgü uç noktaya (https://login.microsoftonline.com/{TenantId_or_Name} ) işaret edecek şekilde yapılandırılmış çok kiracılı uygulamalar için bir Microsoft Entra dizinin konuk kullanıcılarının oturum açmalarını kabul eder.

Microsoft kimlik platformu uç noktası, kişisel Microsoft hesaplarından ve iş ve okul hesaplarından oturum açmayı kabul eden uygulamalar yazmanızı sağlar. Bu, uygulamanızı tamamen hesaplardan bağımsız olarak yazmanızı sağlar. Örneğin, uygulamanız Microsoft Graph'i çağırırsa, sharepoint siteleri veya dizin verileri gibi iş hesapları için bazı ek işlevler ve veriler kullanılabilir. Ancak kullanıcının postasını okuma gibi birçok eylem için aynı kod hem kişisel hem de iş ve okul hesapları için e-postaya erişebilir.

Microsoft kimlik platformu uç noktası için Microsoft Kimlik Doğrulama Kitaplığı'nı (MSAL) kullanarak tüketici, eğitim ve kurumsal dünyalara erişim elde edebilirsiniz. Azure AD v1.0 uç noktası yalnızca iş ve okul hesaplarından oturum açmayı kabul eder.

Azure AD v1.0 uç noktasını kullanan uygulamaların gerekli OAuth 2.0 izinlerini önceden belirtmeleri gerekir, örneğin:

İzin Kaydı kullanıcı arabirimini gösteren örnek

Doğrudan uygulama kaydında ayarlanan izinler statiktir. Azure portal tanımlanan uygulamanın statik izinleri kodu güzel ve basit tutsa da geliştiriciler için bazı olası sorunlar sunar:

  • Uygulamanın kullanıcının ilk oturum açmasında ihtiyaç duyacağı tüm izinleri istemesi gerekir. Bu, son kullanıcıların ilk oturum açmada uygulamanın erişimini onaylamasını engelleyen uzun bir izin listesine yol açabilir.

  • Uygulamanın önceden erişeceği tüm kaynakları bilmesi gerekir. Rastgele sayıda kaynağa erişebilecek uygulamalar oluşturmak zordu.

Microsoft kimlik platformu uç noktasıyla, Azure portal uygulama kayıt bilgilerinde tanımlanan statik izinleri yoksayabilir ve bunun yerine artımlı olarak izin isteyebilirsiniz; bu da müşteri ek uygulama özelliklerini kullandığından önceden açık bir izin kümesi istemek ve zaman içinde daha fazla büyüme anlamına gelir. Bunu yapmak için, uygulama kayıt bilgilerinde önceden tanımlamanıza gerek kalmadan, erişim belirteci isterken parametresine yeni kapsamları ekleyerek uygulamanızın ihtiyaç duyduğu kapsamları scope belirtebilirsiniz. Kullanıcı henüz isteğe eklenen yeni kapsamları onaylamadıysa, yalnızca yeni izinlere onay vermeleri istenir. Daha fazla bilgi edinmek için bkz. izinler, onay ve kapsamlar.

Bir uygulamanın parametre aracılığıyla scope dinamik olarak izin istemesine izin vermek, geliştiricilere kullanıcınızın deneyimi üzerinde tam denetim sağlar. Ayrıca, onay deneyiminizi ön yükleyip ilk yetkilendirme isteğinde tüm izinleri isteyebilirsiniz. Uygulamanız çok sayıda izin gerektiriyorsa, zaman içinde uygulamanın belirli özelliklerini kullanmaya çalıştıkları için bu izinleri kullanıcıdan artımlı olarak toplayabilirsiniz.

Bir kuruluş adına yapılan Yönetici onayı hala uygulama için kayıtlı statik izinler gerektirir, bu nedenle bir yöneticinin kuruluşun tamamı adına onay vermesi gerekiyorsa uygulama kayıt portalındaki uygulamalar için bu izinleri ayarlamanız gerekir. Bu, kuruluş yöneticisinin uygulamayı ayarlaması için gereken döngüleri azaltır.

Kaynaklar değil kapsamlar

v1.0 uç noktasını kullanan uygulamalar için, bir uygulama kaynak veya belirteç alıcısı olarak davranabilir. Bir kaynak, anladığı bir dizi kapsam veya oAuth2Permission tanımlayabilir ve istemci uygulamalarının belirli bir kapsam kümesi için bu kaynaktan belirteç istemesine olanak sağlar. Microsoft Graph API bir kaynak örneği olarak düşünün:

  • Kaynak tanımlayıcısı veya AppID URI: https://graph.microsoft.com/
  • Kapsamlar veya oAuth2Permissions: Directory.Read, Directory.Write, vb.

Bu, Microsoft kimlik platformu uç noktası için geçerlidir. Bir uygulama yine de kaynak olarak davranabilir, kapsamları tanımlayabilir ve bir URI ile tanımlanabilir. İstemci uygulamaları yine de bu kapsamlara erişim isteyebilir. Ancak, bir istemcinin bu izinleri isteme yöntemi değişmiştir.

v1.0 uç noktası için Azure AD OAuth 2.0 yetkilendirme isteği şuna benzer olabilir:

GET https://login.microsoftonline.com/common/oauth2/authorize?
client_id=2d4d11a2-f814-46a7-890a-274a72a7309e
&resource=https://graph.microsoft.com/
...

Burada kaynak parametresi, istemci uygulamasının yetkilendirme istediği kaynağı belirtir. Azure AD, uygulamanın gerektirdiği izinleri Azure portal statik yapılandırmaya göre hesapladı ve belirteçleri buna göre verdi.

Microsoft kimlik platformu uç noktasını kullanan uygulamalar için aynı OAuth 2.0 yetkilendirme isteği şöyle görünür:

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=2d4d11a2-f814-46a7-890a-274a72a7309e
&scope=https://graph.microsoft.com/directory.read%20https://graph.microsoft.com/directory.write
...

Burada kapsam parametresi, uygulamanın yetkilendirme istediği kaynağı ve izinleri gösterir. İstenen kaynak istekte hala mevcuttur; kapsam parametresinin her bir değerini kapsar. Kapsam parametresinin bu şekilde kullanılması, Microsoft kimlik platformu uç noktasının OAuth 2.0 belirtimiyle daha uyumlu olmasını sağlar ve yaygın sektör uygulamalarıyla daha yakından uyumludur. Ayrıca uygulamaların artımlı onay vermesine de olanak tanır. Yalnızca uygulama ön onay yerine izin istediğinde izin isteyebilir.

İyi bilinen kapsamlar

Çevrimdışı erişim

Microsoft kimlik platformu uç noktasını kullanan uygulamalar, uygulamalar offline_access için kapsam olarak bilinen yeni bir izin kullanılmasını gerektirebilir. Tüm uygulamaların, kullanıcı etkin olarak uygulamayı kullanmamış olsa bile uzun bir süre boyunca bir kullanıcı adına kaynaklara erişmesi gerekiyorsa bu izni istemesi gerekir. Kapsam offline_access , onay iletişim kutularındaki kullanıcıya istediğiniz zaman verilerinize erişin şeklinde görünür ve kullanıcının bunu kabul etmesi gerekir. İzin istemek, web uygulamanızın offline_access Microsoft kimlik platformu uç noktasından OAuth 2.0 refresh_tokens almasını sağlar. Yenileme belirteçleri uzun sürelidir ve uzun süreli erişim için yeni OAuth 2.0 erişim belirteçleriyle değiştirilebilir.

Uygulamanız kapsamı istemezse offline_access yenileme belirteçleri almaz. Bu, OAuth 2.0 yetkilendirme kodu akışında bir yetkilendirme kodu kullandığınızda yalnızca uç noktadan bir erişim belirteci /token alacağınız anlamına gelir. Bu erişim belirteci kısa bir süre boyunca (genellikle bir saat) geçerli kalır, ancak sonunda süresi dolar. Bu noktada uygulamanızın yeni bir yetkilendirme kodu almak için /authorize 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 izinlere karşı mutabakata varması gerekebilir veya gerekmeyebilir.

OAuth 2.0, refresh_tokensve access_tokenshakkında daha fazla bilgi edinmek için Microsoft kimlik platformu protokolü başvurusuna bakın.

OpenID, profil ve e-posta

Geçmişte, Microsoft kimlik platformu ile en temel OpenID Connect oturum açma akışı, sonuçta elde edilen id_token kullanıcı hakkında çok fazla bilgi sağlayacaktır. bir id_token talepler kullanıcının adını, tercih edilen kullanıcı adını, e-posta adresini, nesne kimliğini ve daha fazlasını içerebilir.

Kapsamın openid uygulamanıza erişim iznine sahip olduğu bilgiler artık kısıtlanmıştır. Kapsam openid yalnızca uygulamanızın kullanıcıda oturum açmasına ve kullanıcı için uygulamaya özgü bir tanımlayıcı almasına izin verir. Uygulamanızdaki kullanıcı hakkında kişisel veriler almak istiyorsanız uygulamanızın kullanıcıdan ek izinler istemesi gerekir. ve olmak üzere iki yeni kapsam emailprofileek izinler istemenizi sağlar.

  • Kapsam, email kullanıcının adreslenebilir bir e-posta adresine sahip olduğu varsayılarak uygulamanızın id_token talep aracılığıyla email kullanıcının birincil e-posta adresine erişmesini sağlar.
  • Kapsam profile , uygulamanızın kullanıcı hakkında adı, tercih edilen kullanıcı adı, nesne kimliği vb. gibi diğer tüm temel bilgilere id_token erişmesini sağlar.

Bu kapsamlar uygulamanızı çok az açıklamalı bir şekilde kodlamanıza olanak tanır, böylece kullanıcıdan yalnızca uygulamanızın işini yapması için gereken bilgi kümesini isteyebilirsiniz. Bu kapsamlar hakkında daha fazla bilgi için bkz. Microsoft kimlik platformu kapsamı başvurusu.

Belirteç talepleri

Microsoft kimlik platformu uç noktası, yükleri küçük tutmak için belirteçlerinde varsayılan olarak daha küçük bir talep kümesi oluşturur. Artık bir Microsoft kimlik platformu belirtecinde varsayılan olarak sağlanmayan bir v1.0 belirtecindeki belirli bir talepte bağımlılığı olan uygulamalarınız ve hizmetleriniz varsa, bu talebi dahil etmek için isteğe bağlı talepler özelliğini kullanmayı göz önünde bulundurun.

Önemli

v1.0 ve v2.0 belirteçleri hem v1.0 hem de v2.0 uç noktaları tarafından verilebilir! id_tokens her zaman istenen uç noktayla eşleşir ve erişim belirteçleri her zaman istemcinizin bu belirteci kullanarak çağıracağı Web API'sinin beklediği biçimle eşleşir. Dolayısıyla uygulamanız v1.0 biçiminde erişim belirteçleri bekleyen Microsoft Graph'ı çağırmak üzere bir belirteç almak için v2.0 uç noktasını kullanıyorsa, uygulamanız v1.0 biçiminde bir belirteç alır.

Sınırlamalar

Microsoft kimlik platformu kullanırken dikkat etmeniz gereken birkaç kısıtlama vardır.

Microsoft kimlik platformu ile tümleşen uygulamalar oluştururken, Microsoft kimlik platformu uç noktasının ve kimlik doğrulama protokollerinin gereksinimlerinizi karşılayıp karşılamadığına karar vermeniz gerekir. v1.0 uç noktası ve platformu hala tam olarak desteklenir ve bazı bakımlardan Microsoft kimlik platformu daha zengin özelliklere sahiptir. Ancak Microsoft kimlik platformu geliştiriciler için önemli avantajlar sunar.

Geliştiriciler için şimdi basitleştirilmiş bir öneri:

  • Uygulamanızda kişisel Microsoft hesaplarını desteklemek istiyorsanız veya desteklemeniz gerekiyorsa ya da yeni bir uygulama yazıyorsanız Microsoft kimlik platformu kullanın. Ancak bunu yapmadan önce, bu makalede açıklanan sınırlamaları anladığınızdan emin olun.
  • SAML kullanan bir uygulamayı geçiriyor veya güncelleştiriyorsanız Microsoft kimlik platformu kullanamazsınız. Bunun yerine Azure AD v1.0 kılavuzuna bakın.

Microsoft kimlik platformu uç noktası, burada listelenen kısıtlamaları ortadan kaldıracak şekilde geliştirilecek, böylece yalnızca Microsoft kimlik platformu uç noktasını kullanmanız gerekecektir. Bu arada, Microsoft kimlik platformu uç noktasının sizin için uygun olup olmadığını belirlemek için bu makaleyi kullanın. Bu makaleyi, Microsoft kimlik platformu uç noktasının geçerli durumunu yansıtacak şekilde güncelleştirmeye devam edeceğiz. gereksinimlerinizi Microsoft kimlik platformu özelliklere göre yeniden değerlendirmek için tekrar kontrol edin.

Uygulama kayıtlarında kısıtlamalar

Microsoft kimlik platformu uç noktasıyla tümleştirmek istediğiniz her uygulama için, Azure portal yeni Uygulama kayıtları deneyiminde bir uygulama kaydı oluşturabilirsiniz. Mevcut Microsoft hesabı uygulamaları portalla uyumlu değildir, ancak nereye veya ne zaman kaydolduklarına bakılmaksızın tüm Microsoft Entra uygulamalarıdır.

İş ve okul hesaplarını ve kişisel hesapları destekleyen Uygulama kayıtları aşağıdaki uyarılara sahiptir:

  • Uygulama kimliği başına yalnızca iki uygulama gizli dizilerine izin verilir.
  • Kiracıya kaydedilmemiş bir uygulama yalnızca onu kaydeden hesap tarafından yönetilebilir. Diğer geliştiricilerle paylaşılamaz. Uygulama Kayıt Portalı'nda kişisel bir Microsoft hesabı kullanılarak kaydedilen çoğu uygulama için bu durum söz konusudur. Uygulama kaydınızı birden çok geliştiriciyle paylaşmak isterseniz, Azure portal yeni Uygulama kayıtları bölümünü kullanarak uygulamayı bir kiracıya kaydedin.
  • yeniden yönlendirme URL'sinin biçiminde izin verilen çeşitli kısıtlamalar vardır. Yeniden yönlendirme URL'si hakkında daha fazla bilgi için sonraki bölüme bakın.

Yeniden yönlendirme URL'leri üzerindeki kısıtlamalar

Microsoft kimlik platformu için kaydedilen uygulamaların yeniden yönlendirme URL'lerindeki kısıtlamalar hakkında en güncel bilgiler için Microsoft kimlik platformu belgelerindeki Yeniden Yönlendirme URI'si/yanıt URL'si kısıtlamaları ve sınırlamaları konusuna bakın.

Bir uygulamayı Microsoft kimlik platformu kullanmak üzere kaydetmeyi öğrenmek için bkz. Yeni Uygulama kayıtları deneyimini kullanarak uygulama kaydetme.

Kitaplıklar ve SDK'lar üzerindeki kısıtlamalar

Şu anda Microsoft kimlik platformu uç noktası için kitaplık desteği sınırlıdır. üretim uygulamasında Microsoft kimlik platformu uç noktasını kullanmak istiyorsanız şu seçeneklere sahipsiniz:

  • Web uygulaması oluşturuyorsanız oturum açma ve belirteç doğrulama işlemleri için genel kullanıma açık sunucu tarafı ara yazılımını güvenle kullanabilirsiniz. Bunlar ASP.NET için OWIN OpenID Connect ara yazılımını ve Node.js Passport eklentisini içerir. Microsoft ara yazılımını kullanan kod örnekleri için başlangıç Microsoft kimlik platformu bölümüne bakın.
  • Masaüstü veya mobil uygulama oluşturuyorsanız, Microsoft Kimlik Doğrulama Kitaplıklarından (MSAL) birini kullanabilirsiniz. Bu kitaplıklar genel olarak kullanılabilir veya üretim tarafından desteklenen bir önizlemededir, bu nedenle bunları üretim uygulamalarında kullanmak güvenlidir. Önizleme koşulları ve kimlik doğrulama kitaplıklarındaki kullanılabilir kitaplıklar başvurusu hakkında daha fazla bilgi edinebilirsiniz.
  • Microsoft kitaplıkları kapsamında olmayan platformlar için, uygulama kodunuzda protokol iletilerini doğrudan gönderip alarak Microsoft kimlik platformu uç noktasıyla tümleştirebilirsiniz. OpenID Connect ve OAuth protokolleri, böyle bir tümleştirme yapmanıza yardımcı olmak için açıkça belgelenmiştir .
  • Son olarak, Microsoft kimlik platformu uç noktasıyla tümleştirmek için açık kaynak OpenID Connect ve OAuth kitaplıklarını kullanabilirsiniz. Microsoft kimlik platformu uç noktası, değişiklik olmadan birçok açık kaynak protokol kitaplığıyla uyumlu olmalıdır. Bu tür kitaplıkların kullanılabilirliği dile ve platforma göre farklılık gösterir. OpenID Connect ve OAuth 2.0 web siteleri popüler uygulamaların listesini tutar. Daha fazla bilgi için Microsoft kimlik platformu ve kimlik doğrulama kitaplıkları ile Microsoft kimlik platformu uç noktasıyla test edilmiş açık kaynak istemci kitaplıkları ve örnekleri listesine bakın.
  • Başvuru için Microsoft kimlik platformu .well-known ortak uç noktasının uç noktası şeklindedirhttps://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration. değerini kiracı kimliğinizle değiştirerek common kiracınıza özgü verileri alın.

Protokol değişiklikleri

Microsoft kimlik platformu uç noktası SAML veya WS-Federation'ı desteklemez; yalnızca OpenID Connect ve OAuth 2.0'ı destekler. v1.0 uç noktasından OAuth 2.0 protokollerinde dikkate değer değişiklikler şunlardır:

  • email İsteğe bağlı bir talep yapılandırıldıysa veya istekte scope=email belirtildiyse talep döndürülür.
  • scope Parametresi artık parametresi yerine resource desteklenmektedir.
  • Birçok yanıt, OAuth 2.0 belirtimi ile daha uyumlu hale getirmek için değiştirilmiştir; örneğin, dize yerine doğru bir int olarak döndürülmektedir expires_in .

Microsoft kimlik platformu uç noktasında desteklenen protokol işlevselliğinin kapsamını daha iyi anlamak için bkz. OpenID Connect ve OAuth 2.0 protokol başvurusu.

SAML kullanımı

Windows uygulamalarında Active Directory Kimlik Doğrulama Kitaplığı'nı (ADAL) kullandıysanız, Güvenlik Onaylama İşaretleme Dili (SAML) onay iznini kullanan Windows Tümleşik kimlik doğrulamasından yararlanmış olabilirsiniz. Bu izinle, federasyon Microsoft Entra kiracılarının kullanıcıları kimlik bilgilerini girmeden şirket içi Active Directory örneğinde sessizce kimlik doğrulaması yapabilir. SAML kurumsal kullanıcılarla kullanım için desteklenen bir protokol olsa da , v2.0 uç noktası yalnızca OAuth 2.0 uygulamalarıyla kullanım içindir.

Sonraki adımlar

Microsoft kimlik platformu belgelerinde daha fazla bilgi edinin.