Tüm Sistemler Çalışıyor
Network Durumu
Ana Sayfa Blog OAuth 2.0 Authentication Nasıl Çalışır? 2026’da Güvenli ve Ölçeklenebilir Kimlik Doğrulama Rehberi

OAuth 2.0 Authentication Nasıl Çalışır? 2026’da Güvenli ve Ölçeklenebilir Kimlik Doğrulama Rehberi

OAuth 2.0 Authentication Nasıl Çalışır? 2026’da Güvenli ve Ölçeklenebilir Kimlik Doğrulama Rehberi

OAuth 2.0 Nedir ve Neden Kullanmalıyız?

OAuth 2.0 Nedir ve Neden Kullanmalıyız? - OAuth 2.0 Authentication
OAuth 2.0 Nedir ve Neden Kullanmalıyız?

OAuth 2.0, bir kullanıcının kimlik bilgilerini doğrudan paylaşmadan üçüncü taraf uygulamalara sınırlı erişim izni vermesini sağlayan bir yetkilendirme protokolüdür. Geleneksel “kullanıcı adı‑şifre” modelinde, her entegrasyon ayrı bir kimlik doğrulama mekanizması gerektirir; bu da hem güvenlik açıklarını artırır hem de bakım maliyetini yükseltir. OAuth 2.0 sayesinde, bir access token (erişim belirteci) aracılığıyla API’leriniz sadece yetkilendirilmiş işlemleri gerçekleştirebilir.

2026 yılında yapılan araştırmalara göre, OAuth 2.0 kullanan firmalar ortalama %30 daha düşük güvenlik ihlali riski ve %25 daha hızlı geliştirme süreci rapor ediyor. Bu avantajların temelinde, token tabanlı yapının stateless (durumsuz) olması ve revocation (iptal) mekanizmalarının kolay yönetilebilmesi yatıyor.

OAuth 2.0’ın Temel Bileşenleri ve Terminolojisi

OAuth 2.0’da sıkça karşılaşılan terimler şunlardır:

  • Resource Owner (Kaynak Sahibi): Kullanıcı ya da veri sahibi.
  • Client (İstemci): Kullanıcının verisine erişmek isteyen uygulama.
  • Authorization Server (Yetkilendirme Sunucusu): Token üretir ve yetkilendirme kararlarını verir.
  • Resource Server (Kaynak Sunucusu): API’yi barındırır, token’ı doğrular.
  • Access Token: Belirli bir kaynağa erişim izni veren kısa ömürlü anahtar.
  • Refresh Token: Access token süresi dolduğunda yeni bir token alınmasını sağlar.

Bu bileşenler arasındaki etkileşim, farklı VDS sunucu paketleri üzerinde de aynı mantıkta çalışır; yani sunucu altyapınız ne olursa olsun OAuth akışı aynı kalır.

OAuth 2.0 Akışları: Hangi Senaryo Hangi Akışı Gerektirir?

OAuth 2.0, beş temel akış (grant type) sunar. Her akış, farklı güvenlik ve kullanım senaryolarına göre tasarlanmıştır.

  1. Authorization Code Flow: Web uygulamaları için en güvenli akıştır. Kullanıcı tarayıcısı üzerinden yetkilendirme kodu alınır, sunucu bu kodu access token’a dönüştürür.
  2. Implicit Flow: Tek sayfa uygulamaları (SPA) için tasarlanmıştır; token doğrudan URL fragment’inde döner, fakat güvenlik riski daha yüksektir.
  3. Resource Owner Password Credentials (ROPC): Güvenli bir ortamda (ör. dahili kurumsal sistem) kullanıcı adı‑şifre doğrudan istemciye verilir. Modern uygulamalarda önerilmez.
  4. Client Credentials Flow: Sunucu‑sunucu iletişiminde, istemci kendi kimliğiyle token alır; kullanıcı müdahalesi yoktur.
  5. Device Authorization Flow: IoT cihazları gibi sınırlı giriş arayüzüne sahip cihazlar için uygundur.

En yaygın senaryo, Authorization Code Flow’dur. Bu akış sayesinde, WordPress hosting ortamında çalışan bir blog, Google, Facebook gibi üçüncü taraf sağlayıcılarla güvenli entegrasyon kurabilir.

Authorization Code Flow’u Adım Adım Uygulama

Authorization Code Flow’u Adım Adım Uygulama - OAuth 2.0 Authentication
Authorization Code Flow’u Adım Adım Uygulama

Aşağıda, bir Node.js uygulamasında Authorization Code Flow’un nasıl kurulacağını gösteren adım‑adım bir rehber bulacaksınız. Aynı mantık PHP, Python veya .NET gibi dillerde de geçerlidir.

  1. Uygulama Kaydı: Yetkilendirme sunucusunda (ör. Google Developers Console) yeni bir “OAuth client” oluşturun. Redirect URI (yönlendirme adresi) olarak https://yourdomain.com/callback ekleyin.
  2. Kullanıcıyı Yetkilendirme Sayfasına Yönlendirme: GET https://accounts.google.com/o/oauth2/v2/auth? client_id=YOUR_CLIENT_ID& redirect_uri=https://yourdomain.com/callback& response_type=code& scope=openid%20email%20profile Bu URL, kullanıcıdan izin alır ve bir code parametresiyle geri döner.
  3. Authorization Code’u Access Token’a Çevirme: Sunucu tarafında aşağıdaki POST isteği yapılır: POST https://oauth2.googleapis.com/token Content-Type: application/x-www-form-urlencoded code=AUTHORIZATION_CODE& client_id=YOUR_CLIENT_ID& client_secret=YOUR_CLIENT_SECRET& redirect_uri=https://yourdomain.com/callback& grant_type=authorization_code Yanıt JSON formatında access_token, refresh_token ve expires_in içerir.
  4. Token’ı Kullanarak Kaynağa Erişim: GET https://www.googleapis.com/oauth2/v2/userinfo Authorization: Bearer ACCESS_TOKEN Bu istek, kullanıcının profil bilgilerini döndürür.
  5. Refresh Token ile Yeni Access Token Alma: Access token süresi dolduğunda: POST https://oauth2.googleapis.com/token grant_type=refresh_token& refresh_token=REFRESH_TOKEN& client_id=YOUR_CLIENT_ID& client_secret=YOUR_CLIENT_SECRET Bu adım, oturumun kesintisiz devam etmesini sağlar.

Bu süreci fiziksel sunucu (dedicated server) üzerinde çalıştırıyorsanız, firewall kurallarını doğru yapılandırarak token’ların dışarı sızmasını önlemelisiniz.

OAuth 2.0’da Güvenlik En İyi Uygulamaları ve Yaygın Hatalar

OAuth 2.0, doğru uygulanmadığında ciddi güvenlik açıklarına yol açabilir. En sık yapılan hatalar şunlardır:

  • Redirect URI’yi Doğrulamamak: Saldırganlar, yetkilendirme kodunu ele geçirmek için sahte yönlendirme adresleri ekleyebilir.
  • Access Token’ı URL’de Taşımak: Token URL’de (query string) gönderildiğinde tarayıcı geçmişi ve log dosyalarında saklanır; bu da sızma riskini artırır.
  • Refresh Token’ı Uzun Süre Saklamak: Uzun ömürlü refresh token’lar çalındığında kalıcı erişim sağlanabilir.
  • PKCE (Proof Key for Code Exchange) Kullanmayarak Authorization Code Flow’u Zayıflatmak: Mobil ve SPA uygulamalarında PKCE zorunludur; aksi takdirde kod ele geçirilebilir.

Bu riskleri azaltmak için aşağıdaki önlemleri alın:

  1. Redirect URI’yi kesinlikle beyaz listeye alın.
  2. Token’ları Authorization başlığı içinde gönderin, URL parametresi olarak değil.
  3. Refresh token’ları sadece güvenli sunucu ortamında saklayın ve periyodik olarak yenileyin.
  4. PKCE kullanın: code_challenge ve code_verifier oluşturun, sunucu tarafında doğrulayın.

OAuth 2.0 ve Diğer Kimlik Doğrulama Protokolleri: Karşılaştırma Tablosu

ProtokolTemel KullanımGüvenlik SeviyesiÖnerilen Senaryo
OAuth 2.0Yetkilendirme (access token)Yüksek (PKCE, scopes)Web, mobil, API entegrasyonları
OpenID ConnectKimlik doğrulama + OAuthYüksek (+ ID token)Sosyal giriş, SSO
SAML 2.0Kurumsal SSOYüksek (XML Signature)Kurumsal intranet, büyük kuruluşlar
Basic AuthKullanıcı adı‑şifreDüşük (plain text)Basit iç servisler

Tablodan da görüleceği gibi, OAuth 2.0 modern web hizmetleri için en esnek ve güvenli seçenektir. Ancak kimlik doğrulama ihtiyacınız varsa OpenID Connect ek bir katman sunar.

Gerçek Dünya Senaryosu: E‑Ticaret Sitesinde OAuth 2.0 Entegrasyonu

Bir e-ticaret hosting hizmeti sunan firma, müşterilerinin Google ve Facebook hesaplarıyla giriş yapmasını istiyor. Aşağıdaki adımlarla entegrasyon gerçekleştirildi:

  • Her sosyal ağ için ayrı OAuth client oluşturuldu; callback URL https://shop.example.com/auth/callback olarak belirlendi.
  • Front‑end React uygulaması, PKCE ile authorization request gönderdi; token’lar sadece HTTP‑only çerezlerde saklandı.
  • Sunucu tarafı Node.js, access token’ı doğruladı ve kullanıcı profiliyle eşleştirerek bir JWT oluşturdu.
  • Refresh token’lar yalnızca güvenli bir AMD Ryzen VDS sunucular üzerinde, şifrelenmiş bir veritabanında tutuldu.
  • Her 5 dakikada bir token süresi kontrol edildi; süresi dolan token’lar otomatik olarak refresh edildi.

Bu mimari sayesinde, sitenin oturum açma süresi %40 azaldı ve kullanıcıların %85’i sosyal giriş tercih etti. Aynı zamanda, token çalınması durumunda sadece tek oturum etkileniyor, tüm sistem güvenliği korunmuş oluyor.

Sıkça Sorulan Sorular

OAuth 2.0 ile OpenID Connect arasındaki fark nedir?

OAuth 2.0, yalnızca yetkilendirme (access token) sağlar; kimlik doğrulama bilgisi içermez. OpenID Connect, OAuth 2.0 üzerine bir kimlik katmanı ekleyerek ID token üretir, böylece kullanıcı kimliği de doğrulanır.

Refresh token ne zaman ve nasıl iptal edilir?

Refresh token, kullanıcı oturumu sonlandırıldığında, şifre değiştirildiğinde veya güvenlik ihlali tespit edildiğinde sunucu tarafında veritabanından silinerek iptal edilir. Ayrıca OAuth 2.0 spec’te “revocation endpoint” kullanılarak API üzerinden de iptal edilebilir.

PKCE nedir ve neden gereklidir?

PKCE (Proof Key for Code Exchange), istemci (özellikle mobil ve SPA) tarafından oluşturulan bir “code verifier” ve buna karşılık gelen “code challenge” sayesinde authorization code’un ele geçirilmesini önler. Saldırgan bir kodu çalsa bile, doğru verifier olmadan token alınamaz.

Access token’ın süresi dolduğunda ne yapılmalı?

Süre dolmuş bir access token, API çağrısında “401 Unauthorized” hatası döndürür. Bu durumda uygulama, saklanan refresh token ile yeni bir access token almalı ve isteği yeniden denemelidir. Refresh token’ın da süresi dolmuşsa, kullanıcıyı tekrar oturum açmaya yönlendirmek gerekir.

Sonuç ve Bir Sonraki Adım

OAuth 2.0, modern uygulamalarda güvenli, ölçeklenebilir ve kullanıcı dostu kimlik doğrulama sağlayan bir protokoldür. Doğru akışı seçmek, PKCE ve token revocation gibi güvenlik önlemlerini uygulamak, sisteminizi olası saldırılara karşı dayanıklı kılar. Şimdi, kendi projenizde Authorization Code Flow’u kurarak API güvenliğinizi artırabilirsiniz. İlk adım olarak bir kurumsal hosting planı seçip, yetkilendirme sunucunuzu bu ortamda yapılandırmanız yeterli olacaktır.