Azure Active Directory'de (AD) OAuth2 örtük izin akışını anlama

  • Makale

Uyarı

Bu içerik eski Azure AD v1.0 uç noktasına yöneliktir. Yeni projeler için Microsoft kimlik platformu kullanın.

OAuth2 örtük izni, OAuth2 belirtiminde en uzun güvenlik endişeleri listesine sahip olan bir izin olmasıyla ün salmaktadır. Ancak, ADAL JS tarafından uygulanan yaklaşım ve SPA uygulamaları yazarken önerdiğimiz yaklaşım budur. Ne verir? Her şey bir avantajdan ibarettir: Ve ortaya çıkan örtük izin, tarayıcıdan JavaScript aracılığıyla Web API'sini kullanan uygulamalar için izleyebileceğiniz en iyi yaklaşımdır.

OAuth2 örtük izni nedir?

Tam OAuth2 yetkilendirme kodu verme işlemi, iki ayrı uç nokta kullanan yetkilendirme iznidir. Yetkilendirme uç noktası, kullanıcı etkileşimi aşaması için kullanılır ve bu da yetkilendirme koduyla sonuçlanır. Ardından belirteç uç noktası, istemci tarafından bir erişim belirtecinin kodunu ve genellikle bir yenileme belirtecini almak için kullanılır. Yetkilendirme sunucusunun istemcinin kimliğini doğrulayabilmesi için web uygulamalarının belirteç uç noktasına kendi uygulama kimlik bilgilerini sunması gerekir.

OAuth2 örtük izni, diğer yetkilendirme izinlerinin bir çeşididir. İstemcinin, belirteç uç noktasına başvurmadan veya istemcinin kimliğini doğrulamadan doğrudan yetkilendirme uç noktasından erişim belirteci (ve OpenId Connect kullanırken id_token) almasına olanak tanır. Bu değişken bir Web tarayıcısında çalışan JavaScript tabanlı uygulamalar için tasarlanmıştır: özgün OAuth2 belirtiminde belirteçler bir URI parçasında döndürülür. Bu, belirteç bitlerini istemcideki JavaScript kodu için kullanılabilir hale getirir, ancak sunucuya yönelik yeniden yönlendirmelere dahil edilmeyeceklerini garanti eder. OAuth2 örtük verme bölümünde, yetkilendirme uç noktası önceden sağlanan bir yeniden yönlendirme URI'sini kullanarak doğrudan istemciye erişim belirteçleri verir. Ayrıca, JavaScript uygulamasının belirteç uç noktasıyla iletişim kurması gerekiyorsa gerekli olan çıkış noktaları arası çağrıların gereksinimlerini ortadan kaldırma avantajına da sahiptir.

OAuth2 örtük izninin önemli bir özelliği, bu tür akışların hiçbir zaman istemciye yenileme belirteçleri döndürmemesidir. Sonraki bölümde bunun nasıl gerekli olmadığı ve aslında bir güvenlik sorunu olduğu gösterilmektedir.

OAuth2 örtük izni için uygun senaryolar

OAuth2 belirtimi, örtük iznin, tarayıcı içinde yürütülen JavaScript uygulamaları gibi kullanıcı aracısı uygulamalarını etkinleştirmek için geliştirildiğini bildirir. Bu tür uygulamaların belirleyici özelliği, JavaScript kodunun sunucu kaynaklarına erişmek (genellikle bir Web API'si) ve uygulama kullanıcı deneyimini buna göre güncelleştirmek için kullanılmasıdır. Gmail veya Outlook Web Access gibi uygulamaları düşünün: Gelen kutunuzdan bir ileti seçtiğinizde, yalnızca ileti görselleştirme paneli yeni seçimi görüntüleyecek şekilde değişirken, sayfanın geri kalanı değiştirilmeden kalır. Bu özellik, her kullanıcı etkileşiminin tam sayfa geri gönderme ve yeni sunucu yanıtının tam sayfa işlemesiyle sonuçlandığı geleneksel yeniden yönlendirme tabanlı Web uygulamalarının aksinedir.

JavaScript tabanlı yaklaşımı aşırıya götüren uygulamalara tek sayfalı uygulamalar veya SPA'lar denir. Buradaki fikir, bu uygulamaların yalnızca ilk HTML sayfasına ve ilişkili JavaScript'e hizmet ettiği ve sonraki tüm etkileşimlerin JavaScript aracılığıyla gerçekleştirilen Web API çağrıları tarafından yönlendirildiğidir. Ancak, uygulamanın çoğunlukla geri gönderme temelli olduğu ancak zaman zaman JS çağrıları yaptığı karma yaklaşımlar nadir değildir; örtük akış kullanımı hakkındaki tartışmalar da bunlar için geçerlidir.

Yeniden yönlendirme tabanlı uygulamalar genellikle tanımlama bilgileri aracılığıyla isteklerinin güvenliğini sağlar, ancak bu yaklaşım JavaScript uygulamalarında da işe yaramaz. Tanımlama bilgileri yalnızca oluşturuldukları etki alanında çalışırken JavaScript çağrıları diğer etki alanlarına yönlendirilebilir. Aslında bu durum sıklıkla geçerli olacaktır: Microsoft Graph API, Office API'sini, Azure API'sini çağıran uygulamaları düşünün; hepsi uygulamanın sunulduğu yerden etki alanının dışında yer alır. JavaScript uygulamaları için artan bir eğilim, iş işlevlerini uygulamak için üçüncü taraf Web API'lerine %100 bağlı olarak arka ucun hiç olmamasıdır.

Şu anda, bir Web API'sine yapılan çağrıları korumanın tercih edilen yöntemi, her çağrıya OAuth2 erişim belirteci eşlik eden OAuth2 taşıyıcı belirteci yaklaşımını kullanmaktır. Web API'si gelen erişim belirtecini inceler ve gerekli kapsamları bulursa istenen işleme erişim verir. Örtük akış, JavaScript uygulamalarının bir Web API'sine yönelik erişim belirteçlerini alması için kullanışlı bir mekanizma sağlar ve tanımlama bilgileri açısından birçok avantaj sunar:

  • Çıkış noktaları arası çağrılara gerek kalmadan belirteçler güvenilir bir şekilde alınabilir– belirteçlerin döndürüleceği yeniden yönlendirme URI'sinin zorunlu kaydı, belirteçlerin yerinin değiştirilmeyeceğini garanti eder
  • JavaScript uygulamaları, etki alanları üzerinde hiçbir kısıtlama olmadan hedefledikleri kadar Web API'leri için ihtiyaç duydukları kadar erişim belirteci alabilir
  • Oturum veya yerel depolama gibi HTML5 özellikleri, belirteç önbelleğe alma ve yaşam süresi yönetimi üzerinde tam denetim sağlarken tanımlama bilgileri yönetimi uygulama için opaktır
  • Erişim belirteçleri Siteler arası istek sahteciliği (CSRF) saldırılarına açık değildir

Örtük verme akışı, çoğunlukla güvenlik nedeniyle yenileme belirteçleri vermez. Yenileme belirteci erişim belirteçleri kadar dar kapsamlı değildir ve çok daha fazla güç verir ve bu nedenle dışarı sızması durumunda çok daha fazla zarar verir. Örtük akışta belirteçler URL'de teslim edilir, bu nedenle kesme riski yetkilendirme kodu vermesinden daha yüksektir.

Ancak, bir JavaScript uygulaması, kullanıcıdan tekrar tekrar kimlik bilgileri istemeden erişim belirteçlerini yenilemek için başka bir mekanizmaya sahiptir. Uygulama, Azure AD yetkilendirme uç noktasına karşı yeni belirteç istekleri gerçekleştirmek için gizli bir iframe kullanabilir: tarayıcının Azure AD etki alanında etkin bir oturumu (okuma: oturum tanımlama bilgisi var) olduğu sürece, kimlik doğrulama isteği kullanıcı etkileşimi gerekmeden başarıyla gerçekleşebilir.

Bu model, JavaScript uygulamasına erişim belirteçlerini bağımsız olarak yenileme ve hatta yeni API için yeni belirteçler (kullanıcının daha önce onay vermesi koşuluyla) alma olanağı verir. Bu, yenileme belirteci gibi yüksek değerli bir yapıtın elde edilmesi, bakımının ve korunmasının getirdiği ek yükü önler. Sessiz yenilemeyi mümkün kılan yapıt olan Azure AD oturum tanımlama bilgisi, uygulamanın dışında yönetilir. Bu yaklaşımın bir diğer avantajı, kullanıcının Azure AD oturum açmış uygulamalardan herhangi birini kullanarak tarayıcı sekmelerinden herhangi birinde çalıştırarak Azure AD oturumu kapatabilmesidir. Bu, Azure AD oturum tanımlama bilgisinin silinmesiyle sonuçlanır ve JavaScript uygulaması oturumu kapatan kullanıcının belirteçlerini yenileme özelliğini otomatik olarak kaybeder.

Örtük hibe uygulamam için uygun mu?

Örtük izin, diğer izinlere göre daha fazla risk sunar ve dikkat etmeniz gereken alanlar iyi belgelenmiştir (örneğin, Örtük Akışta Kaynak Sahibinin Kimliğine Bürünmek için Erişim Belirtecinin Kötüye Kullanılması ve OAuth 2.0 Tehdit Modeli ve Güvenlikle İlgili Dikkat Edilmesi Gerekenler). Bununla birlikte, daha yüksek risk profili büyük ölçüde etkin kod yürüten ve uzak bir kaynak tarafından bir tarayıcıya sunulan uygulamaları etkinleştirmeye yönelik olmasından kaynaklanır. SPA mimarisi planlıyorsanız, arka uç bileşeniniz yoksa veya JavaScript aracılığıyla bir Web API'sini çağırmayı planlıyorsanız, belirteç alımı için örtük akışın kullanılması önerilir.

Uygulamanız yerel bir istemciyse örtük akış uygun değildir. Yerel istemci bağlamında Azure AD oturum tanımlama bilgisinin olmaması, uygulamanızı uzun süreli bir oturum sürdürme araçlarından mahrum eder. Bu, uygulamanızın yeni kaynaklar için erişim belirteçleri alırken kullanıcıya sürekli olarak soracağı anlamına gelir.

Arka uç içeren bir Web uygulaması geliştiriyorsanız ve arka uç kodundan bir API kullanıyorsanız, örtük akış da uygun değildir. Diğer bağışlar size çok daha fazla güç verir. Örneğin, OAuth2 istemci kimlik bilgileri izni, kullanıcı temsilcilerinden farklı olarak uygulamanın kendisine atanan izinleri yansıtan belirteçleri alma olanağı sağlar. Bu, bir kullanıcı etkin olarak oturum açmadığında bile istemcinin kaynaklara programlı erişimi koruyabilme özelliğine sahip olduğu anlamına gelir. Sadece bu değil, aynı zamanda bu tür izinler daha yüksek güvenlik garantileri verir. Örneğin, erişim belirteçleri hiçbir zaman kullanıcı tarayıcısında geçiş yapmaz, tarayıcı geçmişine kaydedilme riskini taşımaz ve bu şekilde devam eder. İstemci uygulaması, belirteç isteğinde bulunurken güçlü kimlik doğrulaması da gerçekleştirebilir.

Sonraki adımlar