OAuth 2 Nedir ve Neden Hayatımızda Önemli Bir Yer Tutar?

Modern dijital dünyada, uygulamaların birbirleriyle güvenli bir şekilde etkileşim kurması ve kullanıcı verilerini koruması hiç bu kadar kritik olmamıştı. Peki, bir uygulamanın başka bir uygulamanın kaynaklarına, kullanıcı şifresini bilmeden, güvenli bir şekilde nasıl eriştiğini merak ettiniz mi? İşte bu noktada OAuth 2 devreye giriyor. Bu kapsamlı rehberde, OAuth 2’nin temel prensiplerinden ileri düzey güvenlik pratiklerine kadar her şeyi adım adım öğrenecek, gerçek dünya senaryoları ve kod örnekleriyle konuyu derinlemesine kavrayacaksınız.

OAuth 2 Nedir ve Neden Hayatımızda Önemli Bir Yer Tutar?

Dijital platformlar arasındaki etkileşimler her geçen gün artarken, kullanıcı verilerinin güvenliği ve gizliliği en büyük öncelik haline geldi. Bir web sitesine veya mobil uygulamaya kaydolduğunuzda, genellikle “Google ile Giriş Yap” veya “Facebook ile Devam Et” gibi seçenekler görürsünüz. Bu kolaylık ve güvenliğin arkasındaki temel mekanizma, OAuth 2 olarak bilinir. OAuth 2, bir yetkilendirme çerçevesidir; yani, bir uygulamanın (istemci) başka bir uygulamadaki (kaynak sunucusu) belirli kaynaklara (kullanıcı verileri gibi) kullanıcının (kaynak sahibi) onayıyla ve şifresini paylaşmadan erişmesine izin veren bir protokoldür.

Peki, OAuth 2 neden bu kadar önemli? Geleneksel olarak, bir uygulama başka bir servise erişmek istediğinde, kullanıcıdan o servisin kullanıcı adı ve şifresini girmesi istenirdi. Bu yaklaşım, çeşitli güvenlik riskleri taşıyordu: İstemci uygulama, kullanıcının kimlik bilgilerini saklamak zorunda kalacak, bu da bir veri ihlali durumunda tüm hesaplarının tehlikeye girmesine yol açabilecekti. Ayrıca, kullanıcı, istemci uygulamanın hangi verilere eriştiği konusunda hiçbir kontrole sahip değildi. OAuth 2, bu sorunları ortadan kaldırarak, kullanıcılara erişim izni üzerinde daha fazla kontrol sağlıyor ve hassas kimlik bilgilerini doğrudan istemci uygulamalarla paylaşma ihtiyacını ortadan kaldırıyor.

OAuth 2’nin temelinde dört ana rol bulunur:

• Kaynak Sahibi (Resource Owner): Genellikle son kullanıcıdır. Kendi verilerine (örneğin, e-posta, fotoğraflar, takvim) sahip olan ve bu verilere erişim izni veren kişidir.
• İstemci (Client): Kaynak sahibinin verilerine erişmek isteyen uygulamadır. Bu, bir web uygulaması, mobil uygulama veya masaüstü uygulaması olabilir. İstemcinin, yetkilendirme sunucusuna kayıtlı olması gerekir.
• Yetkilendirme Sunucusu (Authorization Server): Kaynak sahibinin kimliğini doğrular ve istemcinin kaynak sunucusuna erişim yetkisi alması için bir erişim tokenı verir. Genellikle kaynak sunucusu ile aynı kuruluş içinde yer alır.
• Kaynak Sunucusu (Resource Server): Kaynak sahibinin korumalı kaynaklarını barındıran ve erişim tokenını kullanarak bu kaynaklara erişim sağlayan sunucudur. Örneğin, Google Drive veya Facebook API’si.

Bu roller arasındaki etkileşim sayesinde, bir kullanıcının şifresi hiçbir zaman istemci uygulamasına ulaşmaz. Bunun yerine, istemciye belirli bir süre ve belirli kapsamlar dahilinde geçerli olan bir “erişim tokenı” verilir. Bu token, kullanıcının onayıyla, istemcinin kaynak sunucusundaki belirli verilere erişmesini sağlar. Örneğin, bir fotoğraf düzenleme uygulamasının Google Fotoğraflar’ınıza sadece fotoğrafları okuma izni alması ve e-postalarınıza asla erişememesi gibi. Bu model, hem kullanıcı gizliliğini artırır hem de uygulamalar arası entegrasyonları çok daha güvenli hale getirir. Dolayısıyla, OAuth 2 modern API güvenliğinin ve kullanıcı deneyiminin vazgeçilmez bir parçasıdır.

OAuth 2 Akışları (Grant Tipleri): Hangi Senaryoya Hangi Akış Uygun?

OAuth 2, farklı kullanım senaryolarına uyum sağlamak için çeşitli “grant tipleri” veya “yetkilendirme akışları” sunar. Her akış, istemcinin yetkilendirme sunucusundan erişim tokenını nasıl talep ettiğini ve aldığını belirler. Bu akışlar, istemcinin güven seviyesine, uygulamanın türüne (web, mobil, masaüstü, arka plan servisi) ve güvenlik gereksinimlerine göre seçilir. Doğru akışı seçmek, uygulamanızın güvenliği ve işlevselliği için kritik öneme sahiptir.

Yetkilendirme Kodu Akışı (Authorization Code Grant): En Yaygın ve Güvenli Yöntem

Yetkilendirme Kodu Akışı, genellikle geleneksel web uygulamaları ve modern tek sayfa uygulamaları (SPA) ile mobil uygulamalar için önerilen en güvenli ve yaygın kullanılan akıştır. Bu akış, istemcinin hassas erişim tokenını doğrudan almasını engeller ve bunun yerine, önce bir “yetkilendirme kodu” alır. Bu kod, daha sonra yetkilendirme sunucusuyla doğrudan, güvenli bir arka kanal üzerinden erişim tokenı ile değiştirilir.

Akış adımları şu şekildedir:

1. Yetkilendirme İsteği: Kullanıcı, istemci uygulamada bir işlem başlatır (örneğin, “Google ile Giriş Yap”). İstemci, kullanıcıyı yetkilendirme sunucusuna yönlendirir. Bu yönlendirme URL’si, istemcinin kimliğini (client_id), istenen izinleri (scope), yönlendirme URI’sini (redirect_uri) ve bir CSRF koruması için state parametresini içerir.
2. Kullanıcı Onayı: Kullanıcı, yetkilendirme sunucusuna kimlik bilgilerini girerek giriş yapar (eğer daha önce yapmadıysa). Yetkilendirme sunucusu, istemcinin istediği izinleri kullanıcıya gösterir ve kullanıcıdan bu izinleri onaylamasını ister.
3. Yetkilendirme Kodu: Kullanıcı izinleri onayladıktan sonra, yetkilendirme sunucusu kullanıcıyı önceden kayıtlı olan redirect_uri‘ye bir yetkilendirme kodu (code) ve state parametresi ile geri yönlendirir.
4. Token Talebi: İstemci uygulama (arka uç sunucusu), aldığı yetkilendirme kodunu ve kendi client_secret‘ını kullanarak yetkilendirme sunucusuna doğrudan bir HTTP POST isteği gönderir. Bu istek, tarayıcı üzerinden değil, sunucular arası güvenli bir bağlantı üzerinden yapılır.
5. Erişim Tokenı: Yetkilendirme sunucusu, yetkilendirme kodunu ve istemci kimlik bilgilerini doğrular. Başarılı olursa, istemciye bir erişim tokenı (access_token), bir yenileme tokenı (refresh_token – isteğe bağlı) ve tokenın geçerlilik süresi (expires_in) ile birlikte yanıt verir.
6. Kaynak Erişimi: İstemci, aldığı erişim tokenını kullanarak kaynak sunucusundaki korumalı kaynaklara erişmek için API çağrıları yapar.

PKCE (Proof Key for Code Exchange) uzantısı, özellikle genel istemciler (native mobil uygulamalar ve SPA’lar) için Yetkilendirme Kodu Akışı’nı daha da güvenli hale getirir. PKCE, yetkilendirme kodunun çalınması durumunda bile kötü niyetli bir uygulamanın erişim tokenı almasını engeller. İstemci, yetkilendirme isteği sırasında tek kullanımlık bir “code verifier” oluşturur ve bunun hash’ini (code_challenge) gönderir. Token talebi sırasında ise orijinal code_verifier‘ı göndererek kimliğini kanıtlar. Bu, yetkilendirme kodunu dinleyen bir saldırganın bile doğru code_verifier olmadan token alamamasını sağlar.

Yetkilendirme isteği örneği:

GET https://örnek.com/oauth/authorize?
  response_type=code&
  client_id=uygulama_kimliği&
  redirect_uri=https://uygulama.com/callback&
  scope=email%20profile&
  state=rastgele_değer&
  code_challenge=S256HashDeğeri&
  code_challenge_method=S256

Token değişimi örneği (arka uçtan cURL ile):

curl -X POST https://örnek.com/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code&
      code=yetkilendirme_kodu&
      redirect_uri=https://uygulama.com/callback&
      client_id=uygulama_kimliği&
      client_secret=uygulama_gizli_anahtarı&
      code_verifier=orijinal_rastgele_değer"

İstemci Kimlik Bilgileri Akışı (Client Credentials Grant): Uygulamadan Uygulamaya Güvenli İletişim

Bu akış, son kullanıcıdan herhangi bir etkileşim veya onay gerektirmeyen, doğrudan istemci ile yetkilendirme sunucusu arasındaki bir akıştır. Genellikle, bir uygulamanın kendi kaynaklarına erişmesi veya bir arka plan servisinin başka bir servisin API’sine erişmesi gerektiğinde kullanılır. Yani, kaynak sahibi bizzat istemcinin kendisi veya istemcinin kontrol ettiği bir varlıktır.

Örnek kullanım alanları:

• Mikroservisler arası iletişimde, bir servisin diğer bir servisin API’sine erişmesi.
• Arka plan görevleri veya cron işleri, kullanıcı adına değil, uygulamanın kendi adına işlem yapması gerektiğinde.
• Yönetim panelleri veya araçları, genel API’leri çağırmak için.

Bu akışta, istemci, kendi client_id ve client_secret bilgilerini kullanarak doğrudan yetkilendirme sunucusundan bir erişim tokenı talep eder. Kullanıcı yönlendirmesi veya onayı adımı yoktur.

Token talebi örneği (cURL ile):

curl -X POST https://örnek.com/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials&
      client_id=uygulama_kimliği&
      client_secret=uygulama_gizli_anahtarı&
      scope=api_erisim_kapsamı"

Implicit Akışı (Implicit Grant) ve Parola Akışı (Resource Owner Password Credentials Grant): Neden Artık Tercih Edilmiyorlar?

OAuth 2’nin ilk sürümlerinde popüler olan bu iki akış, modern güvenlik pratikleri ışığında artık önerilmemektedir ve mümkünse kullanılmamalıdır.

• Implicit Akışı: Tek sayfa uygulamaları (SPA) için tasarlanmıştı ve erişim tokenını doğrudan tarayıcıdaki URL fragment’ı olarak döndürüyordu. Ancak, bu tokenların URL geçmişinde kalması, tarayıcı uzantıları tarafından okunabilmesi ve CSRF saldırılarına karşı savunmasız olması gibi güvenlik zafiyetleri nedeniyle terk edildi. Günümüzde SPA’lar için PKCE ile birlikte Yetkilendirme Kodu Akışı tercih edilmektedir.
• Parola Akışı: Bu akışta, istemci doğrudan kullanıcının kullanıcı adı ve şifresini alarak yetkilendirme sunucusuna gönderir ve erişim tokenı talep eder. Bu, kullanıcının kimlik bilgilerini doğrudan istemci uygulamasına vermesini gerektirdiği için büyük bir güvenlik riski taşır. İstemci uygulamasının güvenliği ihlal edilirse, kullanıcının kimlik bilgileri de açığa çıkar. Bu akış yalnızca, kullanıcının istemci uygulamasına tamamen güvendiği ve başka bir yetkilendirme akışının mümkün olmadığı çok özel durumlarda (örneğin, aynı kuruluşa ait, son derece güvenilir, birinci taraf uygulamalar) kullanılmalıdır. Genellikle, bu akış yerine Yetkilendirme Kodu Akışı (PKCE ile) veya uygunsa diğer akışlar tercih edilmelidir.

Her akışın kendine özgü avantajları ve dezavantajları vardır. Uygulamanızın mimarisine, güvenlik gereksinimlerine ve kullanıcı deneyimi hedeflerine en uygun akışı seçmek, başarılı bir OAuth 2 entegrasyonunun anahtarıdır.

OAuth 2 Uygulamasında Güvenlik İpuçları ve İleri Düzey Konular

OAuth 2, güçlü bir yetkilendirme çerçevesi olmasına rağmen, yanlış uygulandığında güvenlik zafiyetlerine yol açabilir. Bu nedenle, uygulamaları geliştirirken belirli güvenlik pratiklerine uymak ve ileri düzey konuları göz önünde bulundurmak hayati önem taşır. İşte OAuth 2 uygulamanızı daha sağlam hale getirmek için bazı ipuçları ve püf noktaları.

Token Yönetimi: Erişim ve Yenileme Tokenlarını Güvenle Saklamak

Erişim tokenları ve yenileme tokenları, OAuth 2’nin kalbinde yer alır ve bunların güvenli bir şekilde yönetilmesi en kritik güvenlik konularından biridir. Erişim tokenları genellikle kısa ömürlüdür (örneğin, 5-60 dakika) ve kaynak sunucusuna yapılan API çağrılarını yetkilendirmek için kullanılır. Yenileme tokenları ise daha uzun ömürlüdür (örneğin, günler, haftalar veya aylar) ve süresi dolmuş bir erişim tokenı yerine yeni bir erişim tokenı almak için kullanılır. Bu ayrım, bir erişim tokenı çalınsa bile, saldırganın sınırlı bir süreye sahip olmasını ve yenileme tokenı olmadan sürekli erişim sağlayamamasını sağlar.

Tokenları nerede saklamalıyız?

• Erişim Tokenları:
  • Sunucu Tarafı (Web Uygulamaları): Eğer uygulamanızın bir arka ucu varsa, erişim tokenlarını sunucu tarafında güvenli bir şekilde (örneğin, şifrelenmiş veritabanı veya güvenli bellek alanı) saklamak en iyisidir. Bu sayede tokenlar tarayıcıda doğrudan açığa çıkmaz.
  • Tarayıcı Tarafı (SPA’lar): SPA’lar için durum daha karmaşıktır. localStorage veya sessionStorage kullanmak XSS (Cross-Site Scripting) saldırılarına karşı savunmasızdır. HTTP Only cookie’ler, XSS’e karşı daha güvenli olsa da, CSRF saldırılarına karşı ek önlemler (SameSite attribute, state parametresi) gerektirir. En iyi pratik, tokenları mümkün olduğunca kısa ömürlü tutmak ve yenileme tokenını asla tarayıcıda saklamamaktır.
  • Mobil Uygulamalar: Platforma özgü güvenli depolama mekanizmaları (iOS Keychain, Android Keystore) kullanılmalıdır.
• Yenileme Tokenları:
  • Yenileme tokenları, erişim tokenlarından daha hassastır çünkü daha uzun süre geçerlidirler ve yeni erişim tokenları alınmasını sağlarlar. Bu nedenle, yenileme tokenları asla tarayıcıda (localStorage, sessionStorage) saklanmamalıdır.
  • Sunucu Tarafı: Yenileme tokenları her zaman sunucu tarafında, şifrelenmiş ve güvenli bir şekilde saklanmalıdır.
  • Mobil Uygulamalar: Güvenli depolama alanları (Keychain, Keystore) kullanılmalı ve erişimleri sıkı bir şekilde kontrol edilmelidir.

Token İptali (Revocation): Bir kullanıcının oturumu kapatıldığında veya bir güvenlik ihlali şüphesi olduğunda, erişim ve yenileme tokenlarının yetkilendirme sunucusu tarafından derhal iptal edilmesi önemlidir. Bu, çalınan tokenların kötüye kullanılmasını engeller.

Kapsam (Scope) Yönetimi: Yetkilendirmeyi En Aza İndirmek

Kapsamlar, bir istemcinin kaynak sunucusundaki hangi verilere veya işlevlere erişebileceğini tanımlayan izin setleridir. Örneğin, read:email, write:calendar veya profile gibi kapsamlar olabilir. “En Az Yetkilendirme Prensibi” (Principle of Least Privilege) gereği, istemci uygulamalara yalnızca gerçekten ihtiyaç duydukları kapsamlar verilmelidir. Bu, olası bir güvenlik ihlali durumunda, saldırganın erişebileceği veri miktarını sınırlar.

• İstemcinizin ihtiyaç duyduğu minimum kapsamları belirleyin.
• Kullanıcıya, uygulamanın talep ettiği kapsamları açıkça gösterin ve onayını alın.
• Gereksiz veya geniş kapsamlı izinlerden kaçının.

Güvenlik Açıkları ve Önlemler: OAuth 2’yi Daha Sağlam Hale Getirmek

OAuth 2’nin doğru uygulanması, yaygın web güvenlik açıklarına karşı koruma sağlar. Ancak, bazı özel durumlar ve saldırı vektörleri için ek önlemler almak gerekir.

• CSRF (Cross-Site Request Forgery) Koruması: Yetkilendirme Kodu Akışı’nda state parametresi, CSRF saldırılarını önlemek için kritik öneme sahiptir. İstemci, yetkilendirme isteği gönderirken rastgele, tahmin edilemez bir state değeri oluşturur ve bunu kendi oturumunda saklar. Yetkilendirme sunucusu, kullanıcıyı geri yönlendirdiğinde, state parametresini de geri gönderir. İstemci, gelen state değerini kendi sakladığı değerle karşılaştırmalıdır. Eğer eşleşmezse, isteği reddetmelidir. Bu, saldırganın sahte bir yetkilendirme isteği oluşturup kullanıcının tarayıcısını kullanarak yetkisiz bir işlem yapmasını engeller.
• Redirect URI Doğrulaması: İstemcinin kayıtlı redirect_uri‘leri, yetkilendirme sunucusu tarafından sıkı bir şekilde doğrulanmalıdır. Saldırganların kullanıcıları kötü niyetli bir URI’ye yönlendirmesini (open redirect) engellemek için, yetkilendirme sunucusu yalnızca önceden kayıtlı ve tam eşleşen URI’lere yönlendirme yapmalıdır.
• PKCE (Proof Key for Code Exchange) Kullanımı: Yukarıda da belirtildiği gibi, özellikle genel istemciler (mobil, SPA) için PKCE, yetkilendirme kodunun çalınması durumunda bile erişim tokenının kötüye kullanılmasını engelleyen temel bir güvenlik mekanizmasıdır.
• Client Secret Güvenliği: İstemcinin gizli anahtarı (client_secret), istemci kimlik bilgileri akışı ve yetkilendirme kodu akışında token değişimi için kullanılır. Bu anahtar, yalnızca yetkilendirme sunucusu ve istemcinin arka uç sunucusu arasında bilinmeli ve asla tarayıcıda, mobil uygulamada veya herhangi bir genel istemcide açığa çıkarılmamalıdır.

Mobil Uygulamalar ve OAuth 2: En İyi Pratikler

Mobil uygulamalar, tarayıcı tabanlı uygulamalardan farklı güvenlik zorlukları sunar. Bu nedenle OAuth 2’yi mobil uygulamalarda uygularken bazı özel pratiklere dikkat etmek gerekir.

• Sistem Tarayıcısı Kullanımı: Mobil uygulamalarda OAuth akışını başlatırken, uygulamanın kendi içinde gömülü bir webview yerine, cihazın yerel sistem tarayıcısını (Custom Tabs, SFSafariViewController gibi) kullanmak en güvenli yaklaşımdır. Bu, kullanıcının kimlik bilgilerinin ve oturum çerezlerinin uygulamanın kontrolünden ziyade işletim sisteminin güvenli ortamında işlenmesini sağlar.
• PKCE Zorunluluğu: Mobil uygulamalar “genel istemci” kabul edildiği için, client_secret‘ı güvenli bir şekilde saklayamazlar. Bu nedenle, mobil uygulamalarda Yetkilendirme Kodu Akışı her zaman PKCE ile birlikte kullanılmalıdır.
• Özel URI Şemaları (Custom URI Schemes) veya Universal Links/App Links: Yetkilendirme sunucusunun kullanıcıyı geri yönlendirmesi için özel bir URI şeması (örneğin, myapp://callback) veya Universal Links/App Links gibi derin bağlantı mekanizmaları kullanılır. Bu URI’ler, uygulamanın kurulumu sırasında işletim sistemine kayıtlı olmalı ve yetkilendirme sunucusunda doğru şekilde yapılandırılmalıdır.

Mobil Uyumlu HTML ve CSS (Metinsel Açıklama): OAuth akışı sırasında kullanıcı, yetkilendirme sunucusunun web arayüzüne yönlendirilir. Bu arayüzlerin mobil cihazlarda da sorunsuz bir kullanıcı deneyimi sunması önemlidir. Yetkilendirme sunucusunun kullanıcı arayüzü, responsive tasarım prensiplerine uygun olarak geliştirilmelidir. Bu, HTML’de uygun viewport meta etiketi kullanımı ve CSS’te medya sorguları (@media screen and (max-width: 768px) { ... } gibi) ile farklı ekran boyutlarına uyum sağlanması anlamına gelir. Bu sayede, kullanıcılar hem web hem de mobil platformlarda kolayca izinleri onaylayabilir veya reddedebilir.

Gerçek Dünya Senaryosu: Bir Uygulama Entegrasyonu Nasıl Çalışır?

OAuth 2’nin teorik yapısını anlamak önemlidir, ancak gerçek bir senaryo üzerinden nasıl işlediğini görmek konuyu daha iyi pekiştirecektir. Diyelim ki, bir “Proje Yönetim Sistemi” (PMS) uygulamanız var ve bu uygulamanın kullanıcıların Google Takvim’lerini senkronize etmesine izin vermek istiyorsunuz. Bu entegrasyon, kullanıcıların Google Takvim’indeki etkinlikleri PMS’de görmesini ve PMS’den yeni etkinlikler oluşturmasını sağlayacak.

İşte adım adım bu entegrasyonun Yetkilendirme Kodu Akışı (PKCE ile) kullanarak nasıl gerçekleşeceği:

1. PMS’nin Google’a Kaydı: Öncelikle, PMS uygulamanızın Google API Konsolu’nda bir “istemci” olarak kaydedilmesi gerekir. Bu kayıt işlemi sırasında, Google, uygulamanıza bir client_id ve bir client_secret (arka uç kullanan web uygulamaları için) atar. Ayrıca, Google’a uygulamanızın kullanıcıları yetkilendirme sonrası geri yönlendireceği redirect_uri‘yi (örneğin, https://pms.com/google/callback) bildirmeniz gerekir.
2. Kullanıcı Entegrasyonu Başlatır: Bir kullanıcı PMS uygulamasında oturum açar ve “Google Takvimini Bağla” düğmesine tıklar.
3. PMS, Yetkilendirme İsteği Oluşturur: PMS uygulaması, kullanıcıyı Google’ın yetkilendirme sunucusuna yönlendiren bir URL oluşturur. Bu URL şunları içerir:
   • client_id: PMS’nin Google’daki kimliği.
   • redirect_uri: Google’ın kullanıcıyı yetkilendirme sonrası nereye yönlendireceği.
   • scope: PMS’nin Google Takvim’e hangi izinlerle erişmek istediği (örneğin, https://www.googleapis.com/auth/calendar).
   • state: CSRF koruması için rastgele oluşturulmuş bir değer.
   • code_challenge ve code_challenge_method: PKCE için oluşturulan değerler.

   Kullanıcı bu URL’ye yönlendirilir.

4. Kullanıcı Google’da Kimlik Doğrulaması Yapar ve Onay Verir: Kullanıcı, Google’ın oturum açma sayfasında Google hesabıyla giriş yapar (eğer oturum açık değilse). Ardından Google, PMS uygulamasının talep ettiği izinleri (Takvim’e erişim) kullanıcıya gösterir ve onaylamasını ister.
5. Google, Yetkilendirme Kodu ile Geri Yönlendirir: Kullanıcı izinleri onayladıktan sonra, Google yetkilendirme sunucusu kullanıcıyı PMS’nin önceden kayıtlı redirect_uri‘sine (https://pms.com/google/callback) bir yetkilendirme kodu (code) ve orijinal state değeri ile birlikte geri yönlendirir.
6. PMS, Erişim Tokenı Talep Eder: PMS’nin arka uç sunucusu, aldığı yetkilendirme kodunu, kendi client_id‘sini, client_secret‘ını, redirect_uri‘sini ve PKCE için code_verifier‘ı kullanarak Google’ın token uç noktasına güvenli bir POST isteği gönderir.
7. Google, Erişim Tokenı Verir: Google’ın yetkilendirme sunucusu, tüm bilgileri doğruladıktan sonra PMS’ye bir erişim tokenı, bir yenileme tokenı ve tokenın geçerlilik süresi ile yanıt verir.
8. PMS, Tokenları Saklar ve Kullanır: PMS’nin arka ucu, erişim tokenını ve yenileme tokenını kullanıcının hesabıyla ilişkilendirerek güvenli bir şekilde veritabanında saklar. Artık PMS, bu erişim tokenını kullanarak kullanıcının Google Takvim API’sine çağrılar yapabilir (örneğin, etkinlikleri okuyabilir, yeni etkinlikler oluşturabilir). Erişim tokenının süresi dolduğunda, PMS yenileme tokenını kullanarak Google’dan yeni bir erişim tokenı alabilir.

Bu senaryo, kullanıcının Google şifresini asla PMS uygulamasıyla paylaşmak zorunda kalmadan, PMS’nin Google Takvim’e güvenli ve kontrollü bir şekilde erişmesini sağlar. Bu, hem kullanıcı deneyimini iyileştirir hem de hassas bilgilerin güvenliğini garanti altına alır.

Sonuç ve Sıkça Sorulan Sorular

OAuth 2, modern web ve mobil uygulamaların birbirleriyle güvenli bir şekilde etkileşim kurmasını sağlayan güçlü ve esnek bir yetkilendirme çerçevesidir. Kullanıcıların kimlik bilgilerini doğrudan üçüncü taraf uygulamalarla paylaşma ihtiyacını ortadan kaldırarak, hem veri güvenliğini artırır hem de kullanıcıya kendi verileri üzerindeki kontrolü geri verir. Doğru yetkilendirme akışını seçmek, kapsamları dikkatli bir şekilde yönetmek ve PKCE gibi güvenlik uzantılarını kullanmak, sağlam ve güvenli bir OAuth 2 uygulamasının temelini oluşturur. Bu rehberde ele aldığımız temel kavramlar, akışlar ve güvenlik pratikleri, OAuth 2’yi sıfırdan anlamanıza ve uygulamalarınızda güvenle kullanmanıza yardımcı olacaktır.

Unutmayın ki OAuth 2 sürekli gelişen bir standarttır ve en iyi pratikler zamanla değişebilir. Bu nedenle, güncel güvenlik tavsiyelerini takip etmek ve uygulamanızı düzenli olarak gözden geçirmek her zaman önemlidir. OAuth 2, dijital ekosistemde güvenli ve sorunsuz entegrasyonların anahtarıdır.

Sıkça Sorulan Sorular

OAuth 2 bir kimlik doğrulama protokolü müdür?

Hayır, OAuth 2 bir yetkilendirme protokolüdür. Temel amacı, bir uygulamanın (istemci) başka bir servisteki (kaynak sunucusu) belirli kaynaklara kullanıcının onayıyla erişim yetkisi almasını sağlamaktır. Kimlik doğrulama (kullanıcının kim olduğunu kanıtlama) sürecini doğrudan yönetmez. Ancak, genellikle OpenID Connect (OIDC) gibi kimlik doğrulama katmanları OAuth 2 üzerine inşa edilerek hem yetkilendirme hem de kimlik doğrulama sağlanır.

state parametresi ne işe yarar?

state parametresi, özellikle Yetkilendirme Kodu Akışı’nda CSRF (Cross-Site Request Forgery) saldırılarını önlemek için kullanılır. İstemci uygulama, yetkilendirme isteği gönderirken rastgele ve tahmin edilemez bir state değeri oluşturur ve bunu kendi oturumunda saklar. Yetkilendirme sunucusu, kullanıcıyı geri yönlendirdiğinde bu state değerini de geri gönderir. İstemci, gelen state değerini kendi sakladığı değerle karşılaştırarak, isteğin orijinal kendisi tarafından başlatıldığından emin olur ve kötü niyetli bir saldırganın sahte bir istek enjekte etmesini engeller.

Erişim tokenı ve yenileme tokenı arasındaki fark nedir?

Erişim tokenı (Access Token), istemcinin kaynak sunucusundaki korumalı kaynaklara erişmek için kullandığı kısa ömürlü bir kimlik bilgisidir. Genellikle JWT (JSON Web Token) formatında olup belirli bir süre (örneğin 1 saat) geçerlidir. Süresi dolduğunda yeni bir token alınması gerekir. Yenileme tokenı (Refresh Token) ise daha uzun ömürlü bir kimlik bilgisidir ve süresi dolmuş bir erişim tokenı yerine yeni bir erişim tokenı almak için kullanılır. Bu ayrım, erişim tokenının çalınması durumunda bile saldırganın sınırlı bir süreye sahip olmasını ve yenileme tokenı olmadan sürekli erişim sağlayamamasını sağlar, bu da güvenliği artırır.

PKCE neden önemlidir?

PKCE (Proof Key for Code Exchange), özellikle genel istemciler (native mobil uygulamalar ve tek sayfa uygulamaları – SPA’lar) için Yetkilendirme Kodu Akışı’nın güvenliğini artıran bir uzantıdır. Genel istemciler, client_secret gibi gizli kimlik bilgilerini güvenli bir şekilde saklayamazlar. PKCE, yetkilendirme kodu çalınsa bile, kötü niyetli bir uygulamanın bu kodu kullanarak erişim tokenı almasını engeller. Bunu, yetkilendirme isteği sırasında gönderilen bir “code challenge” ve token değişimi sırasında gönderilen “code verifier” ile sağlar, bu da istemcinin kimliğini doğrulamak için ek bir kanıt katmanı ekler.

Hangi OAuth 2 akışını kullanmalıyım?

Çoğu modern web uygulaması, mobil uygulama ve tek sayfa uygulaması (SPA) için Yetkilendirme Kodu Akışı (Authorization Code Grant), özellikle PKCE ile birlikte, en güvenli ve önerilen yöntemdir. Uygulamadan uygulamaya veya arka plan servisleri arasındaki iletişim için ise İstemci Kimlik Bilgileri Akışı (Client Credentials Grant) uygundur. Implicit Akışı ve Parola Akışı güvenlik zafiyetleri nedeniyle artık önerilmemektedir ve kullanılmamalıdır.