Sosyal giriş (OAuth) ile üyelikte güvenlik nasıl sağlanır?

Neden yalnız sosyal giriş?

Takma adlı bir topluluk platformunda parola ve e-posta kaydını tamamen kaldırıp yalnız sosyal girişe izin vermek ilk bakışta kısıtlayıcı görünebilir. Ama bu tercih üç önemli kazanç sağlar. Birincisi, platform parola saklamaz; sızdırılacak bir parola veritabanı yoktur. İkincisi, her hesap doğrulanmış bir dış kimliğe bağlıdır; bu da toplu sahte hesap açmayı zorlaştırır. Üçüncüsü, yasal yükümlülükler açısından hesabın arkasında belirli bir sağlayıcı kimliği bulunur.

Bedeli de vardır: Sosyal hesabı olmayan ya da kullanmak istemeyen kişiler dışarıda kalır ve platform, sağlayıcının erişilebilirliğine kısmen bağımlı hâle gelir. Birden fazla sağlayıcı sunmak bu bağımlılığı azaltır. Sosyal giriş ile üyelik bu nedenle tek bir sağlayıcıya değil, ortak bir adaptör arayüzüne göre tasarlanmalıdır.

Akışın temel taşları

Güncel uygulamalarda önerilen yöntem, yetkilendirme kodu akışının PKCE ile birlikte kullanılmasıdır. Kullanıcı sağlayıcının onay ekranına yönlendirilir, onay verdiğinde platforma kısa ömürlü bir kod döner, platform da bu kodu arka uçta erişim belirteciyle takas eder. PKCE, kodun yolda ele geçirilmesi durumunda bile başka biri tarafından kullanılmasını engeller. Durum parametresi ise isteği başlatan oturumla geri dönen yanıtı eşleştirerek siteler arası istek sahteciliğine karşı koruma sağlar.

OpenID Connect destekleyen sağlayıcılarda kimlik belirtecinin imzası, yayıncısı, hedef kitlesi ve geçerlilik süresi mutlaka arka uçta doğrulanmalıdır. Belirteci yalnız çözüp içindeki e-posta alanına güvenmek, sık rastlanan ve tehlikeli bir kısa yoldur. Tek kullanımlık rastgele değer kullanmak da tekrar saldırılarına karşı ek bir katman sağlar.

En az kapsam ilkesi

Sağlayıcıdan istenen her ek izin, hem kullanıcının güvenini azaltır hem de platformun saklaması gereken veri miktarını artırır. Bir dertleşme platformunun ihtiyacı çoğu zaman temel profil kimliği ve e-posta adresiyle sınırlıdır. Arkadaş listesi, profil fotoğrafı ya da paylaşım izni istemek gereksizdir; üstelik sosyal hesaptaki fotoğrafın yanlışlıkla kamusal avatar olarak kullanılması gibi ciddi sızıntılara kapı açar.

Bu yüzden demo kurulumda sağlayıcıdan gelen ad ve e-posta yalnız gizli kimlik kaydına yazılır; kamusal görünüm hiçbir koşulda bu alanlara erişemez. Avatar, kullanıcının platformda seçtiği ya da yüklediği görseldir ve sağlayıcıdaki profil fotoğrafıyla hiçbir bağı yoktur.

Kapsam listesini belirli aralıklarla gözden geçirmek de iyi bir alışkanlıktır. Bir özellik kaldırıldığında ona bağlı olarak istenen izin de listeden çıkarılmalıdır. Kullanılmayan bir izin, yalnızca risk taşıyan bir yüktür ve sağlayıcıların inceleme süreçlerinde de soru işareti yaratabilir.

Hesap bağlama ve e-posta tuzağı

Kullanıcı bir gün Google ile, ertesi gün Apple ile giriş yaparsa ne olur? Pek çok sistem iki hesabı aynı e-posta adresine bakarak otomatik birleştirir. Bu, hesap ele geçirme açısından riskli bir davranıştır: E-posta adresi doğrulanmamış bir sağlayıcı üzerinden başka birinin hesabına erişim sağlanabilir. Daha güvenli yaklaşım, hesabı sağlayıcı ve sağlayıcı kullanıcı kimliği çiftiyle tanımlamak, farklı bir sağlayıcıyı bağlamak için kullanıcının mevcut hesabıyla oturum açmış olmasını şart koşmaktır.

Apple gibi bazı sağlayıcılar kullanıcıya gerçek e-postasını gizleme seçeneği sunar. Platform bu durumda yönlendirme adresini almaya hazır olmalı ve e-posta adresini bir kimlik anahtarı olarak değil, yalnız iletişim bilgisi olarak görmelidir.

Oturum yönetimi

Sosyal giriş tamamlandıktan sonra platform kendi oturumunu açar ve sağlayıcının belirtecini çoğu zaman saklamasına gerek kalmaz. Oturum çerezi yalnız sunucu tarafından okunabilir, güvenli bağlantıda gönderilen ve siteler arası isteklerde kısıtlanan biçimde ayarlanmalıdır. Kullanıcıya hesap ayarlarında açık oturumlarını, hangi cihazdan ve hangi zaman diliminde açıldıklarını gösteren bir liste ile tek tek kapatma imkânı sunmak, güveni artıran küçük bir ayrıntıdır.

Her oturum açılışında IP adresi, kaynak port, zaman damgası ve cihaz bilgisi trafik kaydına yazılır. Bu kayıt kullanıcının kamusal görünümüne hiçbir zaman yansımaz; yönetim panelinde de varsayılan olarak maskeli durur.

Oturum süresi de bilinçli seçilmelidir. Çok uzun oturumlar, ortak kullanılan bir cihazda başkasının hesaba erişmesine yol açabilir; çok kısa oturumlar ise kullanıcıyı sürekli yeniden girişe zorlar. Hesap ayarlarında “tüm cihazlardan çık” seçeneği bu dengeyi kullanıcının eline bırakır.

Demodan gerçeğe geçiş

Kuytuna demosunda sağlayıcı onay ekranı bir benzetimdir ve gerçek bir bağlantı kurulmaz; ekranda bu açıkça yazar. Gerçek kurulumda her sağlayıcı için bir geliştirici uygulaması oluşturmak, yönlendirme adreslerini kaydetmek, istemci gizli anahtarlarını güvenli bir sır deposunda tutmak ve sağlayıcıların inceleme süreçlerinden geçmek gerekir. Sağlayıcı adaptörleri ortak bir arayüze göre yazıldığından, demodaki benzetim adaptörünün yerine gerçek adaptörü takmak uygulamanın geri kalanını etkilemez.

Briefikir, sosyal giriş ile üyelik kurmak isteyen ekipler için bu adaptörleri, sır yönetimini ve oturum katmanını kurabilir. Sağlayıcıların kendi koşulları ve onay süreçleri ise işletmenin kendi hesabı üzerinden yürütülür.

Sık rastlanan uygulama hataları

Sosyal giriş entegrasyonlarında tekrar tekrar karşılaşılan hatalar vardır. Yönlendirme adresini joker karakterle kaydetmek, saldırganın kodu kendi adresine yönlendirmesine kapı açabilir; bu adresler her zaman tam ve sabit olmalıdır. İstemci gizli anahtarını mobil uygulamanın ya da tarayıcı kodunun içine gömmek de bir başka klasik hatadır; bu anahtar yalnız arka uçta bulunmalıdır.

Hata mesajlarında sağlayıcıdan gelen ham yanıtı kullanıcıya göstermek, iç ayrıntıları dışarı sızdırabilir. Son olarak, sağlayıcı tarafında kullanıcı uygulamaya verdiği izni geri çektiğinde platformun bunu fark edip oturumu sonlandırabilmesi de unutulmaması gereken bir ayrıntıdır.