OAuth 2.1 spesifikasyonu planlandı. OAuth 2.0 ve OAuth 2.1 arasındaki temel farkları ve bunların Logto'da nasıl benimsendiğini keşfedelim.
OAuth 2.0 (RFC 6749) 2012'de çıktığından beri, web ve mobil uygulamalar dünyası büyük ölçüde değişti. İnsanlar masaüstü bilgisayarlardan mobil cihazlara geçiş yapıyor ve Tek Sayfa Uygulamaları (SPA'ler) artık popülerleşti. Ayrıca birçok yeni çerçeve ve web teknolojisi ortaya çıktı. Tüm bu değişikliklerle birlikte, güvenlik zorlukları da arttı. En son web teknolojilerine ayak uydurabilmek için OAuth 2.0'ı güçlendirmek amacıyla Proof Key for Code Exchange (PKCE) gibi yeni RFC'ler sürekli olarak yayınlandı. Günümüzün güvenlik gereksinimleri için en iyi uygulamaları bir araya getirmek son derece önemli hale geldi ve bu yüzden OAuth 2.1 geliyor.
Yaklaşan OAuth 2.1 spesifikasyonunda, OAuth Çalışma Grubu tüm en iyi uygulamaları ve güvenlik önerilerini tek bir belgeye toplamayı amaçlıyor. Logto'da, OAuth'un en son standartlarına ve en iyi uygulamalarına ayak uyduruyoruz. Bu makalede, OAuth 2.0 ve OAuth 2.1 arasındaki temel farkları ve bunların Logto'da nasıl benimsendiğini keşfedeceğiz.
OAuth 2.1'deki en önemli değişikliklerden biri, Yetkilendirme Kodu akışını kullanan tüm OAuth istemcileri için Proof Key for Code Exchange (PKCE) zorunlu hale gelmesidir. PKCE, yetkilendirme kodu müdahale saldırılarını engelleyen bir güvenlik uzantısıdır. Özellikle mobil ve Gizli Anahtarın güvenli bir şekilde saklanamayacağı Tek Sayfa Uygulamaları (SPA'ler) için oldukça faydalıdır.
OAuth istemcileri, sırları güvenli bir şekilde saklayabilme yeteneklerine göre iki farklı tipe ayrılabilir:
Gizli müşteriler: Bu istemciler sırları güvenli bir şekilde saklayabilir, örneğin sunucuda üretilen web uygulamaları ve web sunucuları. Tüm yetkilendirme ile ilgili istekler sunucu tarafından yapılır ve istemci sırrının açığa çıkma riski düşüktür.
Genel müşteriler: Bu müşteriler sırları güvenli bir şekilde saklayamaz, örneğin mobil uygulamalar ve SPA'ler. İstemci sırrı istemci tarafındaki koddan kolayca çıkarılabilir ve saldırganlardan korumak zor olabilir.
Genel müşteriler için PKCE, sahip olunması gereken bir güvenlik önlemidir. Bu, yetkilendirme kodunun yalnızca yetkilendirme isteğini başlatan istemci tarafından değiştirilebileceğini garanti eder.
PKCE, rastgele bir kod doğrulayıcı ve kod doğrulayıcısına dayalı bir kod zorluğu oluşturarak çalışır. Kod doğrulayıcı, yetkilendirme sunucusuna gönderilir ve kod doğrulayıcısını doğrulamak için kod mücadelesi, bir erişim belirteci için yetkilendirme kodunu değiştirirken kullanılır.
OAuth 2.1'de, PKCE Yetkilendirme Kodu akışını kullanan tüm OAuth istemcileri için zorunlu hale gelir, gizlilik durumlarına bakılmaksızın — ister gizli ister genel. Bu önemli değişiklik, olası yetkilendirme kodu müdahale saldırılarına karşı alınan önlemleri temin eder.
Logto'da, PKCE doğrulama akışı hem genel hem de gizli müşteriler için otomatik olarak etkinleştirilmiştir.
SPA'ler ve mobil uygulamalar için, Logto'da yetkilendirme kodu akışını korumak için PKCE sahip olunması gereken bir güvenlik önlemidir. Kod zorluğu olmayan herhangi bir yetkilendirme isteği, Logto'nun yetkilendirme sunucusu tarafından derhal reddedilecektir.
Geleneksel web uygulamaları olan gizli müşterilere gelince, eski uyumluluğu geliştirmek için Logto, yetkilendirme isteğinde kod zorluğunun çıkartılmasına izin verir. Ancak, gizli müşterilerin yetkilendirme isteğinde kod zorluğunu ekleyerek PKCE'yi kabul etmelerini, genel istemcilerin uygulamalarını takip etmelerini şiddetle tavsiye ederiz.
Bir Yönlendirme URI'sı (Tekdüzen Kaynak Tanımlayıcı), kullanıcının kimlik doğrulama ve yetkilendirme sürecinden sonra yetkilendirme sunucusu tarafından geri yönlendirildiği belirli bir uç nokta veya URL'dir.
OAuth akışı sırasında, müşteri uygulaması, ilk yetkilendirme isteğinin bir parçası olarak bir Yönlendirme URI'sı içerir. Kullanıcı kimlik doğrulama sürecini tamamladığında, yetkilendirme sunucusu bir Yetkilendirme Kodu içeren bir yanıt oluşturur ve kullanıcıyı belirtilen Yönlendirme URI'sına geri yönlendirir. Orijinal Yönlendirme URI'sından herhangi bir sapma, kod veya belirteç sızıntısına yol açacaktır.
Yönlendirme URI'larının tam dize eşleşmesi, ilk olarak OAuth 2.0 Güvenlik En İyi Geçerli Uygulamaları bölüm 4.1'de tanıtıldı. Bu uygulama, Yönlendirme URI'sının yetkilendirme sunucusuyla kaydedilenle tam olarak eşleşmesi gerektiğini belirtir. Kaydedilmiş Yönlendirme URI'sından herhangi bir sapma, bir hata yanıtına yol açar.
Topluluk tarafından Yönlendirme URI'ları için joker karakter eşleştirmenin uygulanmasıyla ilgili birçok talep aldık. Joker karakter eşleştirme, özellikle çok sayıda rastgele alt alan adı olan geliştiriciler için çoklu alt alan adlarını veya yolları yönetmek için kolaylık sağlayabilirken, aynı zamanda açık yönlendirme saldırıları gibi güvenlik risklerini de beraberinde getirir. Yönlendirme URI doğrulamasının eksikliğinin neden olduğu tehlikeleri pratik bir şekilde belirlemenin bir örneğini görmek için OAuth güvenlik özetimizin blog gönderisine göz atın.
OAuth 2.1'in sıkı güvenlik standartları doğrultusunda, Logto Yönlendirme URI'larının tam dize eşleşmesini kullanır. Bu karar, OAuth akışının güvenliğini ön planda tutar. Joker karakter eşleşmesi yerine, geliştiricilerin tüm olası Yönlendirme URI'larını Logto yetkilendirme sunucusuna kaydetmelerini teşvik ediyoruz. Bu, Yönlendirme URI'larının tam doğrulanmasını sağlar ve potansiyel güvenlik açıklarının azaltılmasına yardımcı olur.
OAuth 2.0'daki örtük yetkilendirme akışı, erişim belirtecinin kullanıcı kimlik doğrulamasından sonra URL parçasında doğrudan döndüğü SPA'ler için tasarlanmıştı. Bu yöntem kolaydı çünkü ek bir belirteç değişim adımından kaçınıyor ve istemcinin belirteci doğrudan almasını sağlıyordu.
Ancak, bu kolaylık beraberinde bazı dezavantajlar getirdi. Erişim belirteci, tarayıcı geçmişi, yönlendirici başlıkları veya diğer yollarla yetkisiz taraflara ifşa edilebilir, bu da özellikle erişim belirteçleri uzun süre geçerli olduğunda güvenlik ihlallerini daha kolay hale getirir. Örneğin, kötü niyetli bir taraf tarafından yetkilendirme isteği engellendiğinde, URL parçasından kolayca erişim belirteci çıkarabilir ve kullanıcıyı taklit edebilirler.
OAuth 2.0 Güvenlik En İyi Geçerli Uygulamaları açıkça belirtmiştir ki:
İstemciler, örtük yetkilendirme (cevap türü "token") veya yetkilendirme yanıtında erişim belirteçleri veren diğer cevap türlerini KULLANMAMALIDIR.
Böylece, Örtük Akış resmi olarak OAuth 2.1 spesifikasyonundan çıkarılmıştır.
Logto'da, PKCE'li yetkilendirme kodu akışı SPA'ler ve Mobil Uygulamalar için desteklenen tek akıştır. Yetkilendirme kodu akışı, yetkilendirme kodunu değiştirerek erişim belirteçlerini elde etmek için daha güvenli bir yol sağlar.
Kaynak sahibi parola kimlik bilgileri (ROPC) yetkilendirmesi, istemcinin kullanıcının kullanıcı adı ve şifresini bir erişim belirteci karşılığında değiştirmesine olanak tanır. Bu, OAuth 2.0 spesifikasyonunda, HTTP temel kimlik doğrulaması veya daha güvenli OAuth belirteçli akışları kullanamayan eski uygulamalara destek vermek amacıyla tanıtılmıştı.
ROPC yetkilendirme türü, OAuth 2.0 spesifikasyonunda öneri dışı olarak işaretlenmiştir, çünkü kullanıcı kimlik bilgileri istemci uygulamasına ifşa edilmektedir, bu da potansiyel güvenlik ihlallerine yol açabilir. İstemci uygulaması kullanıcının kimlik bilgilerini saklayabilir ve istemci tehlikeye girerse, kullanıcının kimlik bilgileri saldırganlara ifşa edilebilir.
Daha sonra OAuth 2.0 Güvenlik En İyi Geçerli Uygulamaları bölüm 2.4'te, ROPC yetkilendirme türünün kullanılmaması gerektiğine dair vurgusu artırılmıştır. Sonuç olarak, ROPC yetkilendirme türü OAuth 2.1 spesifikasyonundan çıkarılmıştır.
ROPC yetkilendirme türüyle ilişkili yüksek güvenlik riskleri nedeniyle, Logto hiçbir zaman bunu desteklemedi. Eğer hala eski uygulamalarınızda doğrudan kullanıcı kimlik bilgileri akışını kullanıyorsanız, yetkilendirme kodu akışı veya müşteri kimlik bilgileri yetkilendirmesi gibi daha güvenli bir yönteme geçmenizi şiddetle tavsiye ederiz. Logto, bu güvenli OAuth akışlarını uygulamalarınıza sorunsuz bir şekilde entegre etmenize yardımcı olacak çeşitli SDK'lar ve öğreticiler sunar.
Geliştiricilerin en iyi ürün deneyimi için kendi kullanıcı giriş arayüzlerini tasarlamak veya kendi ortamlarında barındırmak istemelerini anlıyoruz. Logto'da, marka ayarları ve özel CSS dahil olmak üzere bir dizi giriş deneyimi (SIE) özelleştirme seçeneği sunuyoruz. Ayrıca, kendi kullanıcı arayüzünü getirme ve doğrudan giriş gibi birkaç devam eden proje sunuyoruz, böylece geliştiricilere kendi giriş arayüzlerini sunarken OAuth akışının güvenliğini sağlama konusunda daha fazla esneklik sunuyoruz.
OAuth 2.1, günümüzün güvenlik zorluklarını ele almayı hedefleyen ve modern web ve mobil uygulama ihtiyaçlarını karşılayacak şekilde tasarlanmış OAuth protokolünün en son yükseltmesidir. OAuth çalışma grubu, OAuth 2.1'in en son güvenlik standartlarına ve en iyi uygulamalarına uygun olmasını sağlamak için aktif olarak güncellemeler yapıyor ve ince ayarlar yapıyor. En son taslak, Mayıs 2024'te yayınlanan OAuth 2.1 11, nihai hale gelmesine doğru önemli bir ilerlemeyi işaret ediyor. Yaklaşan geniş çaplı benimsemeyle birlikte, herkesin OAuth 2.1'de özetlenen en iyi uygulamaları takip etmesini ve güvenliği artırmasını ve kullanıcı deneyimini geliştirmesini şiddetle tavsiye ediyoruz.