Sıfır Güven için belirteçleri yönetme

  • Makale

uygulama geliştirme Sıfır Güven, uygulamanızın amacını ve kaynak erişim gereksinimlerini özellikle tanımlamak önemlidir. Uygulamanız yalnızca istenen şekilde çalışması için gereken erişimi istemelidir. Bu makale, bir geliştirici olarak uygulamanızın Microsoft kimlik platformu alabileceği kimlik belirteçleri, erişim belirteçleri ve güvenlik belirteçleriyle uygulamalarınızda güvenlik oluşturmanıza yardımcı olur.

Uygulamanızın Sıfır Güven en az ayrıcalık ilkesine uyduğunu ve amacınızı tehlikeye atacak şekilde kullanımı önlediğinden emin olun. Tam Zamanında ve Yeterli Erişim (JIT/JEA), risk tabanlı uyarlamalı ilkeler ve veri koruması ile kullanıcı erişimini sınırlayın. Uygulamanızın hassas ve güçlü bölümlerini ayırarak bu alanlara yalnızca yetkili kullanıcı erişimi sağlayın. Uygulamanızı kullanabilen kullanıcıları ve uygulamanızda sahip oldukları özellikleri sınırlayın.

Uygulamanızın Microsoft kimlik platformu aldığı kimlik belirteçlerini yönetme şekline ilişkin en az ayrıcalık oluşturun. Kimlik Belirteçlerindeki bilgiler, bir kullanıcının iddia ettikleri kişi olduğunu doğrulamanıza olanak tanır. Kullanıcı veya kuruluşu MFA sağlama, yönetilen cihaz kullanma ve doğru konumda olma gibi kimlik doğrulama koşullarını belirtebilir.

Müşterilerinizin uygulamanıza yönelik yetkilendirmeleri yönetmesini kolaylaştırma. Kullanıcı sağlama ek yükünü ve el ile işlemlere olan ihtiyacı azaltın. Otomatik kullanıcı sağlama, BT yöneticilerinin hedef kimlik depolarında kullanıcı kimliği oluşturma, bakım ve kaldırmayı otomatikleştirmesine olanak tanır. Müşterileriniz, Microsoft Entra Id'de uygulama sağlama veya İk temelli sağlama ile kullanıcılar ve gruplarda yapılan değişikliklere göre otomasyonları temel alabilir.

Uygulamalarınızda belirteç taleplerini kullanma

Uygulamanızın içindeki UX için kimlik belirteçlerinde talepleri bir veritabanında anahtar olarak kullanın ve istemci uygulamasına erişim sağlayın. Kimlik belirteci, OpenID Bağlan(OIDC) tarafından OAuth 2.0'a yapılan temel uzantıdır. Uygulamanız, erişim belirteçlerinin yanında veya yerine kimlik belirteçleri alabilir.

Güvenlik belirteci yetkilendirmesi için standart düzende verilen kimlik belirteci, uygulamanın kullanıcı hakkında bilgi almasına olanak tanır. Kimlik belirtecini kaynaklara erişmek için yetkilendirme işlemi olarak kullanmayın. Yetkilendirme sunucusu, aşağıdakileri içeren kullanıcı bilgileriyle talepler içeren kimlik belirteçleri verir.

  • hedef kitle (aud) talebi, uygulamanızın istemci kimliğidir. Yalnızca API istemci kimliğiniz için belirteçleri kabul edin.
  • Talep tid , belirteci veren kiracının kimliğidir. Talep oid , kullanıcıyı benzersiz olarak tanımlayan sabit bir değerdir. Verileri kullanıcıyla ilişkilendirmeniz gerektiğinde anahtar olarak ve oid taleplerinin benzersiz birleşimini tid kullanın. Verilerinizi Microsoft Entra Id'de kullanıcının kimliğine geri bağlamak için bu talep değerlerini kullanabilirsiniz.
  • Talep sub , kullanıcıyı benzersiz bir şekilde tanımlayan sabit bir değerdir. Konu talebi, uygulamanız için de benzersizdir. Verileri kullanıcıyla ilişkilendirmek için bu talebi kullanırsanız sub verilerinizden çıkıp Microsoft Entra Id'deki bir kullanıcıya bağlamak mümkün değildir.

Uygulamalarınız kapsamı kullanarak openid Microsoft kimlik platformu kimlik belirteci isteyebilir. OIDC standardı, kimlik belirtecinin openid biçimi ve içeriğiyle birlikte kapsamı yönetir. OIDC şu kapsamları belirtir:

  • openid Kullanıcıda oturum açmak ve kimlik belirtecine bir sub talep eklemek için kapsamı kullanın. Bu kapsamlar, uygulamaya ve kullanıcıya özgü bir kullanıcı kimliği sağlar ve UserInfo uç noktasını çağırır.
  • Kapsam, email kimlik belirtecine kullanıcının e-posta adresini içeren bir email talep ekler.
  • Kapsam, profile kimlik belirtecine kullanıcının temel profil özniteliklerine (ad, kullanıcı adı) sahip talepleri ekler.
  • Kapsam, offline_access kullanıcının mevcut olmadığı durumlarda bile uygulamanın kullanıcı verilerine erişmesine olanak tanır.

Microsoft Kimlik Doğrulama Kitaplığı (MSAL), her belirteç isteğine her zaman openid, e-posta ve profile kapsamları ekler. Sonuç olarak, MSAL her zaman veya AcquireTokenInteractive çağrısında AcquireTokenSilent bir kimlik belirteci ve erişim belirteci döndürür. MSAL her zaman kapsamı istemektedir offline_access . İstekte bulunan uygulama kapsamı belirtmediğinde offline_access bile Microsoft kimlik platformu her zaman kapsamı döndürüroffline_access.

Microsoft, erişim belirteçleri vermek için OAuth2 standardını kullanır. OAuth2 standardı bir belirteç aldığınızı söyler, ancak belirteç biçimini veya belirteçte olması gerekenleri belirtmez. Uygulamanızın Microsoft Entra Id'nin koruduğu bir kaynağa erişmesi gerektiğinde, kaynağın tanımladığı bir kapsam kullanmalıdır.

Örneğin, Microsoft Graph uygulamaya geçerli kullanıcının tam kullanıcı profiline ve kiracının adına erişme yetkisi veren kapsamı tanımlar User.Read . Microsoft Graph, bu API'de kullanılabilen tüm işlevler genelinde izinleri tanımlar.

Yetkilendirmenin ardından Microsoft kimlik platformu uygulamanıza bir erişim belirteci döndürür. Kaynağı çağırdığınızda, uygulamanız API'ye HTTP isteğinin yetkilendirme üst bilgisinin bir parçası olarak bu belirteci sağlar.

Belirteç yaşamlarını yönetme

Uygulamalar, kimlik doğrulaması Microsoft Entra ID ile başarıyla tamamlandıktan sonra bir kullanıcı için oturum oluşturabilir. Kullanıcı oturumu yönetimi, bir kullanıcının yeniden kimlik doğrulamasına ne sıklıkta ihtiyaç duyduğunu belirler. Açıkça doğrulanmış bir kullanıcıyı uygulamanın önünde doğru ayrıcalıkla ve doğru süreyle tutma rolü çok önemlidir. Oturum ömrü, kimlik belirtecindeki exp talebi temel almalıdır. Talep exp , kimlik belirtecinin süresinin dolmak üzere olduğu zamandır ve bundan sonra kullanıcının kimliğini doğrulamak için belirteci artık kullanamayacaksınız.

Erişim belirteçleri için exp belirteç yanıtında veya kimlik belirtecindeki talepte sağlanan belirteç ömrünü her zaman dikkate alır. Belirteç ömrünü yöneten koşullar, bir kuruluş için oturum açma sıklığını içerebilir. Uygulamanız belirteç ömrünü yapılandıramıyor. Belirteç ömrü isteyemezsiniz.

Genel olarak belirteçlerin geçerli ve açıklanmamış olması gerekir. hedef kitle talebi (aud) istemci kimliğiniz ile eşleşmelidir. Belirtecin güvenilir bir verenden geldiğine emin olun. Çok kiracılı bir API'niz varsa, yalnızca belirli kiracıların API'nizi çağırabilmesi için filtrelemeyi seçebilirsiniz. Belirtecin ömrünü zorladığınızdan emin olun. Geçerli saatin bu iki talebin nbf exp değerleri içinde olduğundan emin olmak için (önce değil) ve (süre sonu) taleplerini denetleyin.

Son derece uzun veya kısa oturum ömürlerini hedeflemeyin. Verilen kimlik belirtecinin yaşam süresi bu kararı yönlendirsin. Uygulamanızın oturumlarını belirteç geçerliliğinin ötesinde etkin tutmak, BT yöneticisinin yetkisiz erişimi önlemek için belirteç geçerlilik süresi ayarlamasına neden olan kuralları, ilkeleri ve endişeleri ihlal eder. Kısa oturumlar kullanıcı deneyimini düşürür ve güvenlik duruşunu artırmaz. ASP.NET gibi popüler çerçeveler, Microsoft Entra Id kimlik belirtecinin süre sonu süresinden oturum ve tanımlama bilgisi zaman aşımları ayarlamanıza olanak sağlar. Kimlik sağlayıcısının belirteç süre sonu süresine uyulması, kullanıcı oturumlarınızın hiçbir zaman kimlik sağlayıcısının dikte edilen ilkelerden uzun olmamasını sağlar.

Belirteçleri önbelleğe alma ve yenileme

Belirteçleri uygun şekilde önbelleğe alın. MSAL belirteçleri otomatik olarak önbelleğe alır, ancak belirteçlerin kullanım ömrü vardır. Belirteçleri yaşam sürelerinin tamamı boyunca kullanın ve uygun şekilde önbelleğe alın. Aynı belirteci tekrar tekrar sorarsanız, azaltma uygulamanızın daha az yanıt vermesine neden olur. Uygulamanız belirteç verme işlemini kötüye kullandıysa, uygulamanıza yeni belirteçler vermek için gereken süre uzlaşır.

MSAL kitaplıkları, belirteçleri yenileme mekanizması da dahil olmak üzere OAuth2 protokolünün ayrıntılarını yönetir. MSAL kullanmıyorsanız, seçtiğiniz kitaplığın yenileme belirteçlerini etkili bir şekilde kullandığından emin olun.

İstemciniz korumalı bir kaynağa erişmek için bir erişim belirteci aldığında bir yenileme belirteci alır. Geçerli erişim belirtecinin süresi dolduktan sonra yeni erişim/yenileme belirteci çiftlerini almak için yenileme belirtecini kullanın. Diğer kaynaklar için ek erişim belirteçleri almak için yenileme belirteçlerini kullanın. Yenileme belirteçleri kullanıcı ve istemci birleşimine bağlıdır (bir kaynağa veya kiracıya değil). Uygulamanızın izinlere sahip olduğu herhangi bir kaynak ve kiracı birleşiminde erişim belirteçleri almak için yenileme belirteci kullanabilirsiniz.

Belirteç hatalarını ve hatalarını yönetme

Uygulamanız hiçbir zaman erişim belirtecinin içeriğini doğrulamaya, çözmeye, incelemeye, yorumlamaya veya incelemeye çalışmamalıdır. Bu işlemler kesinlikle kaynak API'sinin sorumluluğundadır. Uygulamanız bir erişim belirtecinin içeriğini incelemeye çalışırsa, Microsoft kimlik platformu şifrelenmiş belirteçler Microsoft kimlik platformu uygulamanızın bozulması olasılığı yüksektir.

Nadiren, bir belirteci alma çağrısı ağ, altyapı veya kimlik doğrulama hizmeti hatası veya kesintisi gibi sorunlara bağlı olarak başarısız olabilir. Aşağıdaki en iyi yöntemleri izleyerek belirteç alma hatası oluşursa uygulamanızda kimlik doğrulama deneyiminin dayanıklılığını artırın:

  • Şifreleme ile belirteçleri yerel olarak önbelleğe alın ve güvenli bir şekilde koruyun.
  • Güvenli olmayan kanallarda belirteçler gibi güvenlik yapıtlarını geçirmeyin.
  • Kimlik sağlayıcısından gelen özel durumları ve hizmet yanıtlarını anlayın ve üzerinde işlem yapma.

Geliştiriciler genellikle kaynağın çağrılmasından 401 hatası alma gibi sorunlarda hata ayıklamak için belirteçlerin içine bakma konusunda soruları olur. Daha şifrelenmiş belirteçler erişim belirtecinin içine bakmanızı engelledikçe, erişim belirteçlerinin içine bakmanın alternatiflerini bulmanız gerekir. Hata ayıklama için, erişim belirtecini içeren belirteç yanıtı ihtiyacınız olan bilgileri sağlar.

Kodunuzda, tek tek hata durumları yerine hata sınıflarını denetleyin. Örneğin, sistem izin vermediğinde tek tek hatalar yerine gerekli kullanıcı etkileşimini işleyin. Bu tek tek durumları gözden kaçırabileceğinizden, tek tek hata kodlarını incelemek yerine kullanıcı etkileşimi gibi bir sınıflandırıcıyı denetlemek daha iyidir.

Çağrısına geri AcquireTokenInteractive dönmeniz ve çağrının AcquireTokenSilent gerektirdiği talep sınamalarını sağlamanız gerekebilir. Bunun yapılması, etkileşimli isteğin etkili bir şekilde yönetilmesini sağlar.

Sonraki adımlar