Kaynak Sahibi Parola Kimlik Bilgileri (ROPC) hibe türünü neden kullanımdan kaldırmalısınız
Kaynak Sahibi Parola Kimlik Bilgileri (ROPC) hibe türü eski bir OAuth 2.0 akışıdır ve güvenlik riskleri taşır, bu yüzden kullanımdan kaldırılmalıdır. Bu yazıda, ROPC'yi uygulamalarınızda neden kullanmamanız gerektiğini belirteceğiz.
Giriş
Kaynak Sahibi Parola Kimlik Bilgileri (ROPC) hibe türü, diğer bir deyişle parola hibe türü, bir kullanıcının kullanıcı adı ve parolasını bir erişim belirteciyle değiştiren bir OAuth 2.0 akışıdır. İlk olarak, daha güvenli OAuth belirteçli akışları kullanamayan HTTP temel kimlik doğrulama veya eski yerel uygulamalar gibi eski uygulamaları desteklemek amacıyla OAuth 2.0 spesifikasyonunda tanıtılmıştı.
Ancak, ROPC hibe türü birçok güvenlik riski taşır ve OAuth 2.0 güvenlik en iyi uygulamaları içinde KULLANILMAMALIDIR olarak işaretlenmiştir.
Son zamanlarda, müşterilerimizden ROPC hibe türünü uygulamak için rehberlik veya destek isteyen birçok soru aldık. Bu yazıda, özellikle yeni uygulamalarınız için ROPC hibe türünü neden kullanmamanız gerektiğini açıklayacağız.
ROPC hibe türü vs yetkilendirme kodu akışı
ROPC hibe türü nasıl çalışır
ROPC hibe türü, kullanıcının kullanıcı adı ve parolasını bir erişim belirteciyle değiştiren basit bir akıştır. İstemci uygulama, kullanıcının kimlik bilgilerini doğrudan toplar ve bunları yetkilendirme sunucusuna doğrudan gönderir. Yetkilendirme sunucusu daha sonra kimlik bilgilerini doğrular ve istemciye bir erişim belirteci düzenler.
Yetkilendirme kodu akışı nasıl çalışır
Buna karşılık, yetkilendirme kodu akışı web uygulamaları için önerilen OAuth 2.0 akışıdır. Bu akış, istemci uygulama, yetkilendirme sunucusu ve kullanıcının tarayıcısı arasında birçok adımı ve yönlendirmeyi içerir. Yetkilendirme kodu akışı daha güvenlidir çünkü kullanıcının kimlik bilgilerini istemci uygulamaya maruz bırakmaz.
ROPC hibe türü ile yetkilendirme kodu akışı arasındaki ana fark, ROPC'nin kullanıcının kimlik bilgilerini istemci uygulamaya maruz bırakması, yetkilendirme kodu akışının ise bırakmamasıdır. Kullanıcı kimlik bilgileri yetkilendirme sunucusunda gizli tutulmalıdır. İstemci uygulama, kullanıcı adına bir kaynağa erişim talebinde bulunduğunda, kullanıcıyı kimlik doğrulama ve istemci uygulamayı yetkilendirmek için yetkilendirme sunucusuna yönlendirmelidir. Bu, istemci uygulamasında minimum yetkilendirme verisi tutar.
ROPC hibe türünün güvenlik riskleri
1. Kullanıcı kimlik bilgilerinin ifşası
Daha önce de belirttiğimiz gibi, ROPC hibe türü kullanıcı kimlik bilgilerini istemci uygulamaya maruz bırakır. Bu, istemci uygulamanın kullanıcının kimlik bilgilerini kaydedebileceği veya günlüğe kaydedebileceği ve kullanıcının haberi olmadan yeniden yetkilendirme yapabileceği için önemli bir güvenlik riskidir.
Özellikle mobil uygulama veya tek sayfalı uygulama gibi bir genel istemci uygulaması için, istemci uygulama kolayca kullanıcı kimlik bilgilerini çıkarmak için enjekte edilebilir veya tersine mühendislik uygulanabilir. Ne bir mobil uygulama ne de kullanıcı tarayıcısında çalışan tek sayfalı bir uygulama sırları gizli tutamaz. Bu nedenle, kullanıcının kimlik bilgilerini açığa çıkarmadan kullanıcıyı doğrulayamaz.
Kaynak sahibinin istemci uygulamasıyla güvenilir bir ilişkisi olsa bile, tüm kimlik doğrulama sürecinde istemci uygulaması arada bir adam rolü oynar, başka bir kötü niyetli aktör tarafından tehlikeye atılabilir. Kötü niyetli aktör, kullanıcının kimlik bilgilerini çalabilir ve kullanıcının kaynaklarına erişmek için kullanıcı kılığına girebilir.
Kullanıcı kimlik bilgilerini çalmak için birçok yol vardır, istemci uygulamanın güvenlik duruşuna bağlı olarak, örneğin keylogger'lar, phishing saldırıları veya kötü amaçlı yazılımlar. Ayrıca kimlik bilgileri her yetkilendirme talebinde ağ üzerinden iletilir. Bu, kimlik bilgisi ele geçirilme riskini daha da artırır.
Birden fazla uygulamanızın ROPC hibe türünü kullandığını düşünün, kimlik bilgisi ifşasının potansiyel riski katlanır.
2. ROPC kullanıcı iznini desteklemez
ROPC hibe türü kullanıcı iznini desteklemez. İstemci uygulama kullanıcının kimlik bilgilerini doğrudan topladığında, kullanıcının istemci uygulamasının kaynaklarına erişimini inceleme ve onaylama fırsatı olmaz. Bu, kullanıcının gizliliğini ve güvenini ihlal eder.
Kullanıcılar, hangi istemci uygulamasının kaynaklarına erişebileceğine ve ne kadar süreyle erişebileceğine karar verme hakkına sahip olmalıdır. Özellikle üçüncü taraf uygulamalar için, bir kullanıcı onay mekanizması hem kaynak sahibinin verilerini korumak hem de GDPR gibi veri koruma düzenlemelerine uymak için hayati öneme sahiptir.
3. ROPC çok faktörlü kimlik doğrulamayı desteklemez
Çok faktörlü kimlik doğrulama (MFA), kullanıcının kaynaklarına erişim sağlamak için iki veya daha fazla doğrulama faktörü sağlamasını gerektiren bir güvenlik uygulamasıdır. Bu, kimlik doğrulama sürecine ek bir güvenlik katmanı ekler. ROPC hibe türü MFA'yı desteklemez. Bunun yerine, kimlik do ğrulama sürecini tek faktörle sınırlar ve belirteç talebi sadece kullanıcının kimlik bilgilerine dayanır. ROPC hibe türü ile SMS OTP, e-posta OTP veya WebAuthn gibi zorlama tabanlı kimlik doğrulama mekanizmalarını uygulamak mümkün değildir.
ROPC modern uygulamalarla uyumlu değil
ROPC hibe türü, modern IAM sistemlerini Tek Oturum Açma (SSO) ya da federatif kimlikleri destekleyemeyen eski uygulamaları desteklemek için tasarlanmıştır.
1. ROPC SSO ile uyumlu değil
Tek Oturum Açma (SSO), kullanıcıların bir kez giriş yapmasını ve birden çok uygulamaya zahmetsizce erişmesini sağlayan modern bir kimlik doğrulama mimarisidir.
Merkezi bir IdP, SSO mimarisinde kritik bir rol oynar. Kullanıcının kimlik doğrulama oturumunu yönetir ve istemci uygulamalara belirteçler sağlar. İstemci uygulamalar, kullanıcının kimlik bilgilerini doğrudan toplamak zorunda kalmaz ve kullanıcının kimlik bilgileri IdP içinde gizli tutulur.
ROPC hibe türü SSO'yu desteklemez. İstemci uygulamanın kullanıcının kimlik bilgilerini doğrudan toplaması gerekir, bu da SSO mimarisini bozar. OpenID Connect (OIDC) veya SAML gibi modern SSO sistemleriyle uyumlu değildir.
2. ROPC federatif kimliklerle uyumlu değil
SSO mimarisine benzer şekilde, federatif kimlikler kullanıcıların mevcut kimliklerini kullanarak birden çok üçüncü taraf uygulamaya erişmelerine izin verir. Bir kullanıcı, Google, Facebook veya Twitter gibi bir merkezi IdP'ye birden fazla sosyal hesabını bağlayabilir ve bu sosyal hesapları kullanarak istemci uygulamalarla kimlik doğrulaması yapabilir. Tüm federatif kimlikler IdP tarafından yönetilir ve istemci uygulamalar kullanıcının kimlik doğrulama detaylarının farkında olmaz.
Buna karşılık, ROPC hibe türü, istemci uygulamanın kullanıcının kimlik bilgilerini doğrudan toplamasını gerektirir. Bu, istemci uygulamanın federatif kimlikleri destekleme yeteneğini sınırlar ve kullanıcının kimlik bilgilerini istemci uygulamaya maruz bırakır.
Sonuç
Kaynak Sahibi Parola Kimlik Bilgileri (ROPC) hibe türü güvenlik riskleri taşıyan eski bir OAuth 2.0 akışıdır ve kullanımdan kaldırılmalıdır. Kullanıcının kimlik bilgilerini istemci uygulamaya maruz bırakır, MFA veya SSO gibi modern güvenlik mekanizmalarını desteklemez. Uygulamalarınızda ROPC hibe türünü kullanmaktan kaçınmanızı şiddetle tavsiye ederiz. ROPC hibe türüne dayalı eski kimlik doğrulama sistemlerine sahipseniz, yetkilendirme kodu akışı veya istemci kimlik bilgileri akışı gibi daha güvenli OAuth 2.0 akışlarına geçmeyi düşünün.
Bizimle iletişime geçin uygulamalarınıza güvenli kullanıcı kimlik doğrulama ve yetkilendirme hizmeti entegre etmek veya parola tabanlı kimlik doğrulama sisteminden daha güvenli bir OAuth 2.0 akışına geçmek için yardıma ihtiyacınız varsa. Güvenli ve modern uygulamalar oluşturmanız için buradayız.