OAuth Nedir? OAuth 2.0 ve "Google ile Giriş Yap" Arkasındaki Mekanizma

OAuth nedir?

OAuth 2.0, bir kullanıcının şifresini paylaşmadan, bir uygulamaya başka bir servisteki verisine sınırlı ve geri alınabilir erişim izni vermesini sağlayan yetkilendirme çerçevesidir. Uygulama şifreyi görmez, yerine süreli bir erişim belirteci alır. "Google ile giriş yap" gibi düğmelerin arkasındaki temel mekanizma budur.

Gündelik bir benzetme yapalım. Otele arabayla gittiniz ve vale arabayı park edecek. Ona ana anahtarınızı vermezsiniz, çünkü ana anahtar bagajı, torpidoyu ve motoru da açar. Bunun yerine yalnızca arabayı park etmeye yarayan bir vale anahtarı verirsiniz.

OAuth tam olarak bu vale anahtarı fikridir. Ana anahtar sizin şifrenizdir. Vale anahtarı ise belirli bir iş için, belirli bir süre geçerli olan ve istediğiniz anda iptal edebileceğiniz erişim belirtecidir.

IETF, standardı RFC 6749 olarak yayımladı. Ad, çoğu kaynakta "açık yetkilendirme" anlamına gelen Open Authorization ifadesinden gelir. OAuth nedir sorusunu burada tek bir terim olarak ele alıyoruz, komşu kavramlar için ilgili yazılarımıza kısa bağlantılar veriyoruz.

Vale anahtarı benzetmesi OAuth nedir sorusunu nasıl açıklar?

OAuth öncesi dünyayı düşünün. Bir fatura analiz uygulaması e-postanızdaki faturaları okumak istiyordu. Uygulama sizden e-posta adresinizi ve şifrenizi isterdi, sonra sizin adınıza giriş yapardı.

Bu yöntemin üç büyük sorunu vardı. Uygulama şifrenizi saklıyordu, yani sızıntı olursa tüm hesabınız risk altındaydı. Ayrıca uygulama yalnızca faturayı değil her şeyi okuyabiliyordu. Üstelik erişimi geri almanın tek yolu şifreyi değiştirmekti, bu da diğer bağlı uygulamaları da bozuyordu.

OAuth bu üç sorunu birlikte çözer. Şifre yalnızca sizin ve e-posta servisinin arasında kalır. Uygulama sadece onayladığınız izinleri taşıyan bir belirteç alır. İsterseniz yalnızca o uygulamanın erişimini kapatırsınız.

Bu yüzden OAuth nedir diye sorarsanız, kısa cevap bir yetki devri sistemi olduğudur; şifre değiştirme ya da şifreleme sistemi değildir. Anahtar benzetmesini aklınızda tutarsanız sonraki bölümlerdeki terimler yerine oturur.

OAuth nedir sorusunda dört rol kimdir?

OAuth konuşmalarında dört rol geçer. Bu rolleri birbirine karıştırırsanız belgelerin çoğu size karmaşık gelir. Aşağıdaki liste her rolü vale benzetmesiyle eşleştirir.

• Kaynak sahibi: Verinin gerçek sahibi, yani siz. Benzetmede arabanın sahibisiniz.
• İstemci: Veriye erişmek isteyen uygulama. Benzetmede vale.
• Yetkilendirme sunucusu: Kimliğinizi doğrulayan, onayınızı alan ve belirteç üreten sistem. Benzetmede otelin anahtar teslim masası.
• Kaynak sunucusu: Korunan verinin durduğu servis, çoğunlukla bir API. Benzetmede araba.

Küçük servislerde yetkilendirme sunucusu ile kaynak sunucusu aynı şirkette olur, hatta aynı altyapıda çalışır. Büyük sağlayıcılarda ise ayrı sistemlerdir. Kaynak sunucusunun konuştuğu arayüzü merak ediyorsanız API nedir yazımız bu bağlamı tamamlar.

İstemciyi iki türe ayırırız. Sunucuda çalışan ve bir gizli anahtar saklayabilen uygulamalara gizli istemci denir. Tarayıcıda ya da telefonda çalışan, gizli anahtarı güvenle saklayamayan uygulamalara ise herkese açık istemci denir. Bu ayrım, hangi akışı seçeceğinizi doğrudan belirler.

Yetki kodu akışı adım adım nasıl çalışır?

Yetki kodu akışı (authorization code flow), bugün en yaygın ve en önerilen OAuth akışıdır. Fikir basittir: belirteç tarayıcının adres çubuğunda dolaşmaz. Önce kısa ömürlü bir kod gelir, uygulama da bu kodu arka kanalda belirteçle takas eder.

1. Kullanıcı uygulamada "Google ile giriş yap" benzeri bir düğmeye basar.
2. Uygulama kullanıcıyı yetkilendirme sunucusuna yönlendirir ve hangi izinleri istediğini bildirir.
3. Kullanıcı orada kimliğini doğrular ve izinleri onaylar ya da reddeder.
4. Sunucu kullanıcıyı uygulamanın kayıtlı adresine geri gönderir ve yanında kısa ömürlü bir yetki kodu taşır.
5. Uygulama bu kodu doğrudan sunucuyla konuşarak erişim belirtecine çevirir.
6. Uygulama belirteci kaynak sunucusuna sunar ve izin verilen veriyi alır.

Burada kritik nokta dördüncü ve beşinci adımdır. Kod tek kullanımlıktır ve kısa sürede geçerliliğini yitirir. Belirteç ise tarayıcıdan geçmez, böylece adres geçmişinde, günlüklerde ya da yönlendiren sayfalarda sızma riski azalır.

Ayrıntılar için RFC 6749 belgesinin yetki kodu bölümüne bakabilirsiniz. Ancak günlük işiniz için kavramsal akışı bilmek çoğu zaman yeterlidir.

PKCE nedir ve neden gerekir?

PKCE, "pixy" diye okunan ve kod değişimi için kanıt anahtarı anlamına gelen bir eklentidir. RFC 7636 belgesi bunu tanımlar. Amacı, yetki kodu yolda çalınsa bile kötü niyetli kişinin bu kodu belirtece çevirememesini sağlamaktır.

Mantığı şöyle anlatabiliriz. Uygulama, süreci başlatmadan önce rastgele bir sır üretir. Bu sırrın yalnızca özetini yetkilendirme sunucusuna gönderir. Kodu belirtece çevirirken ise sırrın kendisini sunar. Sunucu özetle sırrı karşılaştırır, uyuşmazsa belirteç vermez.

Dolayısıyla kodu çalan kişi, sır elinde olmadığı için işe yarar bir şey elde edemez. Bu, kapıcıya bırakılan kargo fişine benzer. Paketi yalnızca fişin sahibi alır.

Eskiden PKCE yalnızca mobil uygulamalar ve tarayıcı tabanlı uygulamalar için öneriliyordu. Bugün güvenlik rehberleri, gizli istemciler dahil yetki kodu akışı kullanan her istemci için PKCE kullanmanızı öneriyor. Küçük bir ek emekle önemli bir saldırı sınıfını kapatırsınız.

Kapsam (scope) ve onay ekranı ne anlama gelir?

Kapsam, uygulamanın hangi verilere ve hangi işlemlere erişmek istediğini anlatan izin etiketidir. Örneğin "profil bilgisini oku" ile "takvime etkinlik ekle" iki ayrı kapsamdır. Uygulama yetki isteğinde kapsamları listeler, sağlayıcı da bunları onay ekranında size gösterir.

Onay ekranı sizin vale anahtarını kesmeniz anıdır. Burada okuduğunuz her satır, belirtece yazdığınız bir yetkidir. Bu yüzden onay ekranını hızla geçmek yerine hangi izinleri verdiğinize bakmanız gerekir.

Uygulama geliştiricisi için ilke "asgari yetki"dir. Giriş yapmak için yalnızca temel profil yeterliyse, kişi listesi ya da dosya erişimi istemeyin. Geniş kapsam istemek hem kullanıcının güvenini düşürür hem de belirteç sızarsa zararı büyütür.

İşletme sahibi olarak şunu da bilin: kapsam isteklerini sağlayıcılar denetleyebilir. Hassas kapsamlar için ek doğrulama ya da inceleme gerekebilir. Bu süreçlerin güncel koşullarını sağlayıcının resmi geliştirici belgesinden kontrol edin.

Erişim belirteci ile yenileme belirteci arasındaki fark nedir?

Erişim belirteci, kaynak sunucusuna her istekte sunduğunuz vale anahtarıdır. Kısa ömürlü olmasını isteriz, çünkü çalınırsa zarar süresi sınırlı kalmalıdır. Yenileme belirteci ise yeni erişim belirteci almak için kullanılan, daha uzun ömürlü ve çok daha hassas bir anahtardır.

Benzetmemizde erişim belirteci günlük vale anahtarıdır, yenileme belirteci ise yedek anahtar çıkarma yetkisidir. Birincisi kaybolursa kısa sürede geçersiz olur. İkincisi kaybolursa saldırgan sürekli yeni anahtar üretebilir, bu yüzden güvenli depolamanız şarttır.

OAuth belirteçlerin biçimini dayatmaz. Bazı sağlayıcılar anlamsız, rastgele görünen dizeler üretir. Bazıları ise içinde bilgi taşıyan imzalı biçimler kullanır. Bu biçimin nasıl çalıştığını ayrıca anlattık, JWT yazımız yapıyı ve doğrulamayı ayrıntılı işler. Burada tekrar etmiyoruz.

Pratik kural basittir. Erişim belirtecini asla adres satırına, günlüklere ya da hata mesajlarına yazmayın. Yenileme belirtecini yalnızca sunucu tarafında, güvenli şifreli depoda tutun. Kullanıcı hesabını bağlantıdan çıkardığında ikisini de geçersiz kılın.

Kimlik doğrulama ile yetkilendirme aynı şey midir?

Hayır, aynı şey değildir ve OAuth hakkındaki en yaygın yanlış anlama tam burada başlar. Kimlik doğrulama "bu kişi kim?" sorusunu cevaplar. Yetkilendirme ise "bu kişi ya da uygulama neye erişebilir?" sorusunu cevaplar.

OAuth 2.0 ilk sorudan çok ikinci soruyu hedefler. Erişim belirteci size "bu uygulama takvime erişebilir" der, ancak "karşınızdaki kişi şu kişidir" demez. Bu nedenle yalnızca OAuth belirteci alıp bunu kimlik kanıtı sanmak, zayıf tasarımlara yol açar.

Örneğin bir otelde kapı kartı, kimin içeri girebileceğini söyler. Ancak kartı kimin taşıdığını söylemez. Kart yetki verir, kimlik göstermez.

Sosyal girişte bu boşluğu OpenID Connect doldurur. Bir sonraki bölümde bu katmanı ele alıyoruz.

OpenID Connect, OAuth'a ne ekler?

Kısaca OpenID Connect (OIDC), OAuth 2.0 üzerine kurulan bir kimlik katmanıdır. OpenID Foundation sayfası standardı ve hazır kütüphaneleri tanıtır. OAuth yalnızca erişim belirteci verirken OIDC buna kimlik belirteci ekler.

Kimlik belirteci, kullanıcının kim olduğunu, ne zaman ve nasıl doğrulandığını ve belirtecin hangi uygulama için üretildiğini taşıyan imzalı bir kanıttır. Uygulama bu imzayı doğrulayarak "bu oturumu gerçekten şu sağlayıcı başlattı" sonucuna varır.

OIDC ayrıca standart bir kullanıcı bilgisi ucu ve standart kapsamlar getirir. Profil ve e-posta gibi alanlar her sağlayıcıda aynı adlarla gelir. Böylece her sağlayıcı için ayrı ayrı özel kod yazmazsınız.

Kısacası, OAuth nedir sorusuna giriş açısından bakarsanız "Google ile giriş yap" dediğinizde teknik olarak OpenID Connect kullanırsınız ve OAuth 2.0 bunun taşıyıcı altyapısı olur. Ekibiniz bir sosyal giriş entegrasyonu planlıyorsa, doğru terim çoğu zaman "OIDC ile giriş"tir.

OAuth, OpenID Connect, SAML ve passkey arasında ne fark var?

İnsanlar bu dört terimi sık birbirine karıştırır, çünkü hepsi giriş ve erişim konusuna dokunur. Ancak her biri başka bir sorunu çözer. Aşağıdaki tablo farkı tek bakışta gösterir.

Önemli olan şu: bunlar rakip değil, çoğu zaman birbirini tamamlayan katmanlardır. Bir sağlayıcı kullanıcısını passkey ile doğrulayabilir, sonra OIDC ile size kimlik bilgisini taşıyabilir. Passkey tarafını passkey rehberimiz içinde ayrıntılı anlattık.

SAML daha eski ve XML tabanlıdır, kurumsal dünyada yaygındır. OIDC ise JSON tabanlıdır ve web ve mobilde daha rahat kullanırsınız. Müşteri kitleniz bireysel kullanıcılarsa OIDC genellikle daha doğal bir başlangıç noktasıdır.

"Google ile giriş yap" arkasında hangi adımlar çalışır?

Bir ziyaretçinin sitenizde sosyal giriş düğmesine bastığı anı baştan sona izleyelim. Bu bölüm daha önce anlattığımız parçaları tek bir senaryoda birleştirir. Senaryo bir örnektir, belirli bir sağlayıcının güncel ekranını birebir tarif etmez.

1. Ziyaretçi sitenizde giriş düğmesine basar.
2. Siteniz rastgele bir durum değeri ve PKCE sırrı üretir, bunları oturumda saklar.
3. Tarayıcı sağlayıcının giriş ve onay sayfasına gider.
4. Ziyaretçi sağlayıcıda kimliğini doğrular, istenen izinleri görür ve onaylar.
5. Sağlayıcı ziyaretçiyi sitenize geri gönderir ve kodla durum değerini yanına ekler.
6. Siteniz durum değerini kontrol eder, kodu ve sırrı sunucudan sunucuya göndererek belirteçleri alır.
7. Siteniz kimlik belirtecini doğrular, kullanıcıyı eşleştirir ya da yeni hesap açar ve kendi oturumunu başlatır.

Burada iki ayrı oturum olduğunu fark edin. Sağlayıcıdaki oturum ile sizin sitenizdeki oturum birbirinden bağımsızdır. Sağlayıcı yalnızca "bu kişiyi tanıdım" der, sitenizin oturumunu ise siz yönetirsiniz.

Siteniz durum değerini ikinci adımda üretir, beşinci adımda geri alır. Eşleşmiyorsa isteği reddedersiniz. Bu küçük kontrol, sahte yönlendirmelerle yapılan saldırıları engeller.

OAuth 2.0 uygulamalarında en sık görülen güvenlik hataları nelerdir?

OAuthun kendisi sağlam bir çerçevedir, ancak yanlış uygulama ciddi açıklar doğurur. IETF, {RFC9700} belgesinde bilinen saldırıları ve önlemleri bir araya getirdi. Biz bu belgenin ışığında sahada en sık gördüğümüz hataları özetliyoruz.

• Gevşek yönlendirme adresi doğrulaması: Sağlayıcıda kayıtlı adres ile gelen adres tam olarak eşleşmezse saldırgan kodu kendi adresine yönlendirebilir. Tam eşleşme isteyin, joker karakter kullanmayın.
• Geniş kapsam isteme: Gerekmeyen izinleri istemek, sızıntı halinde zararı büyütür.
• Belirteç sızıntısı: Belirteçleri günlüğe, hata ekranına, adres satırına ya da tarayıcı depolamasına yazarsanız saldırganlar bunları kolayca ele geçirir.
• Durum değerini atlamak: Durum parametresi olmayan akışlar, sahte istek saldırılarına açıktır.
• Sırrı istemci koduna gömmek: Tarayıcıya giden her kod okunabilir, gizli anahtarı orada tutamazsınız.

Bu maddelerin çoğu, genel web güvenliği ilkelerinin OAuth'a uygulanmış halidir. Daha geniş resim için OWASP Top 10 rehberimiz ve veri aktarımını koruyan SSL sertifikası ve HTTPS yazımız faydalı olur.

Eski örtük akış (implicit flow) neden artık önerilmiyor?

Örtük akış, OAuth 2.0 ilk yayımlandığında tarayıcı tabanlı uygulamalar için tasarlanmıştı. Bu akışta belirteç, yetkilendirme sunucusundan doğrudan adres çubuğundaki parça kısmında geri dönüyordu. Yetki kodu ve arka kanal adımı yoktu.

Bu tasarım, belirtecin tarayıcı geçmişine, eklentilere ve sayfadaki diğer kodlara açık olması demekti. Ayrıca belirteci kimin için ürettiğini doğrulamak zordu. Güvenlik en iyi uygulamaları belgesi, örtük akışın ve benzeri belirteç döndüren yanıt türlerinin kullanılmamasını söyler.

Yerine ne kullanırsınız? Tarayıcı tabanlı uygulamalarda bile PKCE ile yetki kodu akışını öneririz. Böylece uygulamanız sunucu desteği olmadan da güvenli kalır. Bir eski sistem devralıyorsanız, ilk denetim maddesi örtük akışı kapatmak olmalıdır.

Bunu tekrar vurgulamamızın nedeni, eski eğitim videolarının ve örnek projelerin hâlâ bu akışı gösterebilmesidir. Eski bir kaynaktan öğrendiğiniz kalıbı canlıya taşımadan önce güncel rehberle karşılaştırın.

Hangi akışı ne zaman seçmelisiniz?

OAuth tek bir akış değildir; farklı istemci türleri için farklı akışlar tanımlar. Seçim, uygulamanızın nerede çalıştığına ve kullanıcının sürece dahil olup olmadığına bağlıdır. Aşağıdaki tablo karar sürecini kolaylaştırır.

Mobil uygulamaların en iyi uygulamalarını RFC 8252 belgesi toplar. Belge, gömülü tarayıcı yerine sistem tarayıcısı kullanmanın nedenlerini de açıklar.

Kullanıcı adı ve şifreyi doğrudan istemciye veren eski şifre akışı da artık tavsiye edilmez. Çünkü bu akış OAuth'un çözmeye çalıştığı sorunu, yani şifreyi üçüncü tarafla paylaşmayı, geri getirir.

İşletme sitesine sosyal giriş eklerken hangi kontrol listesini izlemelisiniz?

OAuth nedir sorusunun iş tarafındaki karşılığı sosyal girişidir. Sosyal giriş, üyelik gerektiren sitelerde formu kısaltır ve şifre unutma yükünü azaltır. Ancak entegrasyon bir kez yapılıp unutulan bir şey değildir. Ekibimizin projelerde kullandığı kontrol listesini aşağıda paylaşıyoruz.

• Gerçekten ihtiyaç olduğunu doğrulayın: kullanıcılarınız hangi sağlayıcılarda hesap sahibi?
• Yalnızca gerekli kapsamları isteyin, e-posta ve temel profil çoğu zaman yeterlidir.
• Yetki kodu akışını PKCE ile kullanın, örtük akışı kapalı tutun.
• Yönlendirme adreslerini sağlayıcı panelinde tam eşleşmeyle kaydedin, test ve canlı ortamları ayırın.
• Durum değerini her istekte üretin ve dönüşte doğrulayın.
• Kimlik belirtecinin imzasını, hedef kitlesini ve geçerlilik süresini sunucuda kontrol edin.
• Belirteçleri günlüğe yazmayın, yenileme belirteçlerini şifreli saklayın.
• Kullanıcıya bağlantıyı kesme ve hesabı silme yolu sunun.
• Sağlayıcının e-postasını güvenilir saymadan önce hesap birleştirme kurallarını tasarlayın.
• Yedek giriş yolu bırakın, çünkü sağlayıcı hesabına erişimini kaybeden kullanıcı sitenizden de kopar.

Kişisel veri açısından da düşünün. Sağlayıcıdan hangi alanları aldığınızı ve neden sakladığınızı gizlilik metninizde belirtmeniz gerekir. Bu konuda KVKK ve GDPR uyumlu web sitesi rehberimiz çerçeveyi toparlar. Bu yazı hukuki danışmanlık değildir, kesin sorular için uzmanınıza danışın.

Giriş sayfanızda güvenli bağlantı kullandığınızdan emin olun. SSL sorgulama aracımız bu kontrolü saniyeler içinde yapar. Giriş için ayrıca parola da sunuyorsanız şifre oluşturucu aracımız kullanıcılarınıza güçlü parola örneği vermenize yardım eder.

Sosyal giriş kullanıcı deneyimine ve dönüşüme ne katar?

Sosyal giriş, kayıt formundaki sürtünmeyi azaltır. Kullanıcı yeni bir şifre üretmez, e-posta doğrulama beklemez ve tek dokunuşla içeri girer. Özellikle mobilde bu fark belirgindir.

Ancak her işletme için doğru çözüm değildir. Bazı kitleler sosyal hesapla giriş yapmak istemez. Bazı sektörlerde kullanıcılar iş ve özel hesabı ayırmayı tercih eder. Dolayısıyla sosyal girişi tek seçenek yapmak yerine, e-posta ile giriş ya da passkey ile birlikte sunmak daha dengelidir.

Ölçmeden karar vermeyin. Sosyal girişi yayına almadan önce kayıt tamamlama oranını, giriş sonrası ilk işlem oranını ve destek taleplerini izleyin. Bu ölçümlerin hangi araçla nasıl yapılacağı sitenizin yapısına göre değişir.

Rakam vermiyoruz, çünkü sektöre, kitleye ve arayüze göre sonuçlar çok değişir. Kendi verinizle küçük bir deneme yapmak, genel iddialardan çok daha güvenilirdir.

Belirteç ömrü ve iptal nasıl işler?

OAuth nedir sorusunun güvenlik tarafındaki en pratik cevabı, belirteçlerin geçici olmasıdır. Erişim belirteci kısa süre sonra kendiliğinden geçersiz olur. Süre dolunca uygulama, yenileme belirteciyle yeni bir erişim belirteci ister.

Bu tasarımın faydası şudur: bir belirteç çalınsa bile saldırganın elindeki anahtar kısa sürede işe yaramaz hale gelir. Yenileme belirteci ise çok daha değerli olduğu için sağlayıcılar onu ek kurallarla korur. Örneğin her kullanımda yeni bir yenileme belirteci verebilir ya da şüpheli kullanımı fark edince hepsini iptal edebilirler.

İptal ise iki yönlüdür. Kullanıcı, sağlayıcıdaki hesap ayarlarından uygulamanın erişimini kaldırabilir. Uygulama da bir kullanıcı hesabını sildiğinde ya da bağlantıyı kopardığında belirteçleri sağlayıcıya bildirerek geçersiz kılabilir. Bu ikinci adımı atlayan uygulamalar, kullanıcı gittikten sonra bile geçerli belirteç taşır.

Belirteç sürelerinin güncel varsayılanları sağlayıcıdan sağlayıcıya değişir. Dolayısıyla sabit bir süre ezberlemek yerine sağlayıcının belgesine bakın ve süreleri kendi risk seviyenize göre ayarlayın.

Bir işletme sahibi OAuth nedir sorusundan ne anlamalı?

Teknik ekibiniz olmasa bile bu kavramın iş kararlarına etkisi vardır. İşletme sahibi olarak kod yazmanız gerekmez, ancak doğru soruları sorabilmeniz gerekir. Aşağıdaki sorular geliştiriciyle ya da ajansla yapacağınız toplantıda işinize yarar.

• Hangi sağlayıcılarla giriş sunacağız ve bunun nedeni ne?
• Kullanıcıdan hangi verileri alacağız ve hangisini gerçekten kullanacağız?
• Belirteçler nerede saklanıyor ve kimler erişebiliyor?
• Kullanıcı bağlantıyı kesmek isterse ne olacak?
• Sağlayıcı koşullarını değiştirirse ya da hesabımıza erişimi kısıtlarsa yedek planımız ne?

Bu soruların cevabı net değilse entegrasyon henüz olgun değildir. Çünkü sosyal giriş, işinizi başka bir şirketin kurallarına bağlar. Sağlayıcı bir gün ayarlarını değiştirebilir, bu yüzden tek bir sağlayıcıya tam bağımlı kalmamak akıllıca olur.

Son olarak veri sorumluluğu sizdedir. Sağlayıcıdan aldığınız her kişisel veri, sitenizin gizlilik yükümlülüğü kapsamına girer. Bu nedenle yalnızca ihtiyacınız olan alanları alın ve nedenini kullanıcıya açıkça anlatın.

OAuth nedir diye öğrenmeye nereden başlamalısınız?

OAuth nedir sorusunu yeni öğrenen biri için en verimli yol, önce kavramı oturtmaktır. Roller, yetki kodu akışı ve kapsam fikri aklınıza yerleşince protokol ayrıntıları kolaylaşır. Ardından küçük bir deneme uygulamasıyla akışı gözlemleyin.

1. Vale anahtarı benzetmesini ve dört rolü kendi cümlelerinizle anlatabilir hale gelin.
2. Yetki kodu akışını bir kâğıda çizin ve her okun neden orada olduğunu söyleyin.
3. PKCE'nin hangi saldırıyı kapattığını öğrenin.
4. Bir sağlayıcının geliştirici belgesini okuyarak sahte bir test uygulaması kaydedin.
5. Güvenlik en iyi uygulamaları belgesini bir kontrol listesine çevirin.

Teknik okur için birincil kaynaklar yeterince açıktır. Standartları kelimesi kelimesine ezberlemeniz gerekmez. Hangi sorunun hangi belgede cevaplandığını bilmeniz yeter.

Ürününüze giriş ya da entegrasyon ekleyecekseniz ve bu işi dışarıdan almak istiyorsanız özel yazılım geliştirme hizmetimiz sayfamızdan bize ulaşabilirsiniz. Kurulumu, güvenlik incelemesini ve belgelemeyi birlikte planlarız. Bulut modelleri konusunda kafanız karışıksa IaaS, PaaS ve SaaS farkı yazımız ilk adım olabilir.

OAuth istemcisi sağlayıcıda nasıl kayıt olur ve istemci kimliği nedir?

Bir uygulama sağlayıcıya ilk kez bağlanmadan önce kayıt yaptırır. Bu kayıtta sağlayıcıya uygulamanın adını, türünü ve izin verilen geri dönüş adreslerini bildirirsiniz. Karşılığında bir istemci kimliği alırsınız. Gizli istemciyseniz ayrıca bir istemci gizli anahtarı da alırsınız.

İstemci kimliği herkese açık olabilir, uygulamanızın kullanıcı adı gibidir. Gizli anahtar ise şifre gibi davranır. Sunucu ortam değişkeninde ya da gizli yönetim aracında saklayın, kaynak koduna ve depoya eklemeyin.

Kayıt sırasında bildirdiğiniz geri dönüş adresleri en kritik alandır. Sağlayıcı, yetki kodunu yalnızca bu listedeki adreslere gönderir. Bu yüzden listeyi dar tutun, test için kullandığınız yerel adresleri canlı uygulama kaydından ayrı bir kayıtta tanımlayın.

Sağlayıcıların geliştirici panelleri ve menü adları değişebilir. Dolayısıyla kesin ekran adları yerine, sağlayıcının güncel geliştirici belgesindeki adımları izleyin. Alan adı örneği olarak biz yalnızca example.com gibi yer tutucular kullanırız.

OAuth 2.0 yalnızca sosyal girişte mi kullanılır?

Hayır, sosyal giriş OAuth'un yalnızca en görünür kullanımıdır. Aslında OAuth, bir uygulamanın başka bir servisin API'sine kullanıcı adına erişmesi gereken her yerde karşınıza çıkar. Giriş bunlardan yalnızca biridir.

• Takvim uygulamanızın e-posta servisindeki toplantı davetlerini okuması.
• Muhasebe yazılımının banka ya da ödeme servisinden hareketleri çekmesi.
• Raporlama panelinizin reklam hesabı verilerini kullanıcı izniyle alması.
• Bir otomasyon aracının sizin adınıza dosya servisine kayıt eklemesi.

Bu senaryoların hepsinde aynı fikir geçerlidir: kullanıcı şifresini vermez, yalnızca belirli bir işi yapan bir yetki verir. İşletmeler için bu, entegrasyon kurarken müşteri ya da çalışan şifresi istemek zorunda kalmamak demektir.

Sunucudan sunucuya çalışan entegrasyonlarda kullanıcı olmadığı için istemci kimlik bilgileri akışını kullanırsınız. Arka plandaki arayüz mantığını API nedir yazımız anlatır. Veri sorgulama modeli açısından GraphQL ve REST farkı yazımız de bu tabloyu tamamlar.

OAuth hakkında hangi yanlış anlamalar yaygındır?

Yeni başlayanların çoğu aynı birkaç yanlış kanıya takılır. Bunları baştan temizlemek, hem okuduğunuz belgeleri hem de ekibinizle yaptığınız toplantıları kolaylaştırır.

• "OAuth bir şifreleme yöntemidir." Hayır, OAuth yetki devri akışıdır. Verinin yolda korunması için HTTPS gerekir.
• "Erişim belirteci kimlik kanıtıdır." Hayır, belirteç yetkiyi gösterir, kişiyi değil. Kimlik için OpenID Connect gerekir.
• "Sosyal giriş kullanırsam güvenlik sorunum biter." Hayır, yalnızca şifre saklama yükü azalır. Oturum yönetimi ve belirteç saklama yine sizin işinizdir.
• "Kütüphane kullanırsam ayar yapmam gerekmez." Hayır, yönlendirme adresi ve kapsam gibi ayarlar sizin sorumluluğunuzdadır.
• "OAuth 2.0 ile OAuth 1.0 aynı şeydir." Hayır, ikisi farklı protokollerdir ve 2.0 sürümü bugün yaygın olandır.

Her yanlış anlama bir güvenlik açığına dönüşebilir. Örneğin belirteci kimlik sanan bir uygulama, başka bir uygulama için üretilmiş bir belirteci kabul edebilir. Bu yüzden hedef kitle kontrolünü hiçbir zaman atlamayın.