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

Sıfır Güven uygulama geliştirmesinde, uygulamanızın amacını ve kaynak erişim gereksinimlerini özel olarak 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 platformundan 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 ilkesine en az ayrıcalıkla bağlı olduğundan ve amacınızı tehlikeye atacak şekilde kullanımı önlediğinden emin olun. Just-In-Time ve Just-Enough-Access (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ırın. 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 platformundan aldığı kimlik belirteçlerini yönetme şekliyle ilgili 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, yönetilen cihazlar ve doğru konumlar gibi kimlik doğrulama koşullarını belirtebilir.

Müşterilerinizin uygulamanıza yönelik yetkilendirmeleri yönetmesini kolaylaştırma. Kullanıcı oluşturma ve yapılandırma ek yükünü ve el ile gerçekleştirilen işlemleri 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 aracılığıyla kullanıcılar ve gruplardaki değişikliklere dayalı otomasyon yapabilir.

Uygulamalarınızda belirteç taleplerini kullanın

Uygulamanızın içindeki kullanıcı deneyimi için kimlik belirteçlerinde hak taleplerini veritabanında anahtar olarak kullanın. İstemci uygulamasına erişim sağlayın. Kimlik belirteci, OpenID Connect'in (OIDC) OAuth 2.0'a yaptığı 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.
  • Belirtilen tid iddia, 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 tid ve oid iddialarının benzersiz birleşimini anahtar olarak kullanın. Verilerinizi Microsoft Entra Id'de kullanıcının kimliğine geri bağlamak için bu talep değerlerini kullanın.
  • 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, openid kapsamını kullanarak Microsoft kimlik platformundan 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 token isteğine her zaman openid, e-posta ve profile kapsamları ekler. Sonuç olarak, MSAL, AcquireTokenSilent veya AcquireTokenInteractive çağrılarının her birinde her zaman bir kimlik belirteci ve bir erişim belirteci döndürür. MSAL, offline_access kapsamını her zaman istemektedir. Microsoft kimlik platformu, istekte bulunan uygulama offline_access kapsamını belirtmese bile offline_access kapsamını her zaman döndürür.

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ı ile erişme yetkisi veren User.Read kapsamını tanımlar. 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.

Token ömürlerini 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 kimlik doğrulamayı yineleme sıklıklarını 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. İddia exp, kimlik belirtecinin süresinin dolduğu zamandır ve bu zaman sonrasında kullanıcının kimliğini doğrulamak için belirteci artık kullanamayacağınız zamandır.

Erişim belirteçleri veya kimlik belirtecindeki exp taleplerde sağlanan belirteç ömrünü her zaman dikkate alın. Jeton ömrünü yöneten koşullar, bir kuruluş için oturum açma sıklığını içerebilir. Uygulamanız jeton ömrünü yapılandıramıyor. Jeton ömrünü talep edemezsiniz.

Genel olarak, belirteçlerin geçerli ve süresi dolmamış olduğundan emin olun. hedef kitle talebi (aud) istemci kimliğiniz ile eşleşmelidir. Belirtecin güvenilir bir verenden geldiğinden 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ü uyguladığınızdan emin olun. Geçerli saatin bu iki talebin nbfexp 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 frameworkler, Microsoft Entra ID belirteci sona erdiğinde oturum ve çerez zaman aşımlarını ayarlamanıza olanak sağlar. Kimlik sağlayıcısının belirlediği politikaların ötesine geçmemesi için kullanıcı oturum sürelerinin kimlik sağlayıcısının belirteç bitiş süresine uygun olmasını sağlayın.

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 talep ederseniz, kısıtlama uygulamanızın daha az duyarlı hale gelmesine neden olur. Uygulamanız belirteç verme işlemini kötüye kullandıysa, uygulamanıza yeni belirteçler verme süresi uzlanı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 erişim belirteci aldığında, aynı zamanda bir yenileme belirteci de 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ı kombinasyonunda erişim belirteçleri almak için bir 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 dağıttığında uygulamanızın bozulması büyük olasılıkla olasıdır.

Nadiren, belirteç alma çağrısı ağ, altyapı veya kimlik doğrulama hizmeti hatası veya kesintisi gibi sorunlara bağlı olarak başarısız olur. 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 nesnelerini geçirmeyin.
  • Kimlik sağlayıcısından gelen istisnaları ve hizmet yanıtlarını anlayın ve bunlar üzerinde işlem yapın.

Geliştiriciler genellikle kaynağa yapılan çağrıdan 401 hatası alma gibi sorunlarda token’ların içine bakarak hata ayıklamak için sorular sorarlar. 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, bireysel hatalar yerine kullanıcı etkileşimini ele alın. 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.

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

Sonraki Adımlar

  • Last updated on