Tüm Sistemler Çalışıyor
Network Durumu
Ana Sayfa Blog OAuth 2.0 Authentication Nedir? 7 Adımda Derinlemesine Kılavuz 2026

OAuth 2.0 Authentication Nedir? 7 Adımda Derinlemesine Kılavuz 2026

OAuth 2.0 Authentication Nedir? 7 Adımda Derinlemesine Kılavuz 2026

OAuth 2.0 Authentication Nedir ve Neden Önemlidir?

OAuth 2.0 Authentication Nedir ve Neden Önemlidir? - OAuth 2.0 Authentication
OAuth 2.0 Authentication Nedir ve Neden Önemlidir?

Günümüzde bir web sitesine ya da mobil uygulamaya giriş yaparken kullanıcıların şifrelerini doğrudan paylaşması hem kullanıcı deneyimini zorlaştırır hem de güvenlik risklerini artırır. İşte bu noktada OAuth 2.0 devreye girer. OAuth 2.0, bir kaynağa (örneğin bir API) erişim izni vermek için üçüncü taraf uygulamalara güvenli bir yol sunar; kullanıcı şifresi hiç uygulamaya aktarılmaz.

Bu protokol, access token adı verilen kısa ömürlü bir anahtar üretir ve bu token sayesinde uygulama, kullanıcının adına belirli bir kaynak üzerinde işlem yapabilir. Örneğin, bir e‑ticaret sitesinde e-ticaret hosting hizmeti sağlayan bir sistem, ödeme sağlayıcısına OAuth 2.0 ile bağlanarak müşterinin kart bilgilerini doğrudan görmez, sadece onay token’ı alır.

Özellikle veri sızıntısı ve kimlik avı saldırılarının %40’a kadar azaltıldığı raporlar, OAuth 2.0’ın sunduğu izole erişim modelinin ne kadar kritik olduğunu gösteriyor. Bu sebeple, modern uygulama geliştirme sürecinde OAuth 2.0’ı doğru yapılandırmak bir zorunluluk haline gelmiştir.

OAuth 2.0’ın Temel Bileşenleri ve Terminolojisi

OAuth 2.0’da beş ana bileşen bulunur: Resource Owner (Kaynak Sahibi), Client (İstemci), Authorization Server (Yetkilendirme Sunucusu), Resource Server (Kaynak Sunucusu) ve Access Token (Erişim Token’ı). Kaynak sahibi genellikle son kullanıcıdır; client ise uygulamanın (web, mobil ya da sunucu tarafı) kendisidir. Yetkilendirme sunucusu, token üretiminden ve onay sürecinden sorumludur; kaynak sunucusu ise token doğrulandıktan sonra gerçek veri servisini sunar.

Bu bileşenler arasındaki iletişim HTTPS üzerinden gerçekleşir, böylece token’ların ele geçirilme riski minimuma indirilir. Token’ın iki temel türü vardır: Bearer Token (taşıyıcı token) ve MAC Token** (Message Authentication Code). Bearer token en yaygın kullanılanıdır; token’ı elinde bulunduran herkes, sunucuya erişim hakkı kazanır.

OAuth 2.0’da kullanılan bir diğer kritik kavram Scope (Kapsam)dır. Scope, istemcinin hangi kaynaklara erişebileceğini sınırlar. Örneğin, bir uygulama sadece “profile” ve “email” scope’larını isteyebilir; “payment” gibi hassas bir scope’a erişim talep etmezse, yetkilendirme sunucusu bu isteği reddeder.

OAuth 2.0 Akış Tipleri (Grant Types) ve Kullanım Senaryoları

OAuth 2.0, farklı senaryolar için çeşitli grant type (yetkilendirme akışı) sunar. En çok kullanılan beş akış şunlardır:

  • Authorization Code Grant: Web uygulamaları için ideal; sunucu tarafında token alınır, böylece client secret gizli kalır.
  • Implicit Grant: Tek sayfa uygulamaları (SPA) ve mobil uygulamalarda tercih edilir; token doğrudan URL fragment’inde döner.
  • Resource Owner Password Credentials Grant: Güvenli bir ortamda (ör. şirket içi sistem) kullanıcı adı/şifre doğrudan client’a gönderilir.
  • Client Credentials Grant: İstemcinin kendisi bir kaynağa erişmek istediğinde (ör. arka plan servisleri) kullanılır.
  • Refresh Token Grant: Access token süresi dolduğunda yeni bir token almak için kullanılır; kullanıcı tekrar oturum açmak zorunda kalmaz.

Örneğin, bir WordPress hosting ortamında bir eklenti, kullanıcıların Google hesabıyla giriş yapmasını sağlamak istiyorsa Authorization Code Grant akışını tercih eder. Bu akış sayesinde, eklenti yalnızca bir authorization code alır, ardından sunucu tarafında access token üretir ve client secret asla istemciye (tarayıcıya) açığa çıkmaz.

Her akışın avantajları ve dezavantajları vardır; seçim yaparken uygulamanın mimarisi, güvenlik gereksinimleri ve kullanıcı deneyimi göz önünde bulundurulmalıdır.

OAuth 2.0 Entegrasyonu: Adım Adım Uygulama Rehberi

OAuth 2.0 Entegrasyonu: Adım Adım Uygulama Rehberi - OAuth 2.0 Authentication
OAuth 2.0 Entegrasyonu: Adım Adım Uygulama Rehberi

Şimdi, bir Node.js API’si için Authorization Code Grant akışını nasıl kuracağınızı adım adım inceleyelim.

  1. OAuth Provider Kaydı: Google, Facebook veya kendi Authorization Server’ınızı (ör. VDS sunucu paketleri üzerinde çalışan bir Identity Server) seçin ve client ID & secret alın.
  2. Redirect URI Tanımlama: Kullanıcı yetkilendirme sonrası yönlendirileceği URL’yi (ör. https://api.ornek.com/auth/callback) provider panelinde kaydedin.
  3. Authorization Request Oluşturma: Kullanıcıyı aşağıdaki gibi bir URL’ye yönlendirin: https://accounts.google.com/o/oauth2/v2/auth?response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=YOUR_REDIRECT_URI&scope=openid%20email%20profile&state=RANDOM_STRING
  4. Authorization Code’u Almak: Kullanıcı onay verdikten sonra provider, code parametresiyle birlikte redirect URI’ye geri döner. Bu kodu sunucu tarafında alın.
  5. Access Token İsteği: Sunucu, code ve client secret ile token endpoint’ine POST yapar:
    POST /token HTTP/1.1
    Host: accounts.google.com
    Content-Type: application/x-www-form-urlencoded
    
    code=AUTHORIZATION_CODE&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&redirect_uri=YOUR_REDIRECT_URI&grant_type=authorization_code
  6. Token Doğrulama ve Kullanma: Gelen JSON yanıtında access_token ve refresh_token bulunur. Access token’ı API isteklerinde Authorization: Bearer ACCESS_TOKEN başlığıyla gönderin.
  7. Refresh Token ile Yenileme: Access token süresi dolduğunda aynı endpoint’e grant_type=refresh_token ile yeni bir token alın.

Bu adımları doğru şekilde uygularsanız, kullanıcı şifresi hiç sisteminizde saklanmaz ve token yönetimi tamamen OAuth sunucusu tarafından kontrol edilir. Ayrıca, fiziksel sunucu (dedicated server) üzerinde çalışan bir Identity Server, yüksek performans ve düşük gecikme (%30 daha hızlı yanıt süresi) sağlar.

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

ÖzellikOAuth 2.0OpenID ConnectSAML 2.0
Temel AmaçErişim yetkilendirmesiKimlik doğrulama + yetkilendirmeKimlik doğrulama
Token TipiBearer / MACID Token (JWT) + Access TokenXML Assertion
Uygulama TipiWeb, mobil, APIWeb, mobil, SPAKurumsal SSO
GüvenlikHTTPS zorunlu, token expirationHTTPS + JWT imzasıXML Signature, Encryption
PerformansHafif JSON, düşük gecikmeJWT sayesinde hızlı doğrulamaXML işleme maliyeti yüksek

Tablodan da görebileceğiniz gibi, OAuth 2.0 hafifliği ve geniş ekosistemiyle API‑first dünyasında öne çıkar. Ancak kimlik doğrulama ihtiyacı varsa, OpenID Connect ek bir katman sunar. SAML ise hâlâ kurumsal ortamlarda yaygın olsa da, JSON‑tabanlı OAuth 2.0 daha modern bir tercih olarak kabul görmektedir.

Yaygın Hatalar ve Maliyeti: Nelerden Kaçınmalısınız?

OAuth 2.0 entegrasyonunda yapılan hatalar, sadece güvenlik açığı yaratmakla kalmaz, aynı zamanda işletme maliyetlerini de artırır. En sık rastlanan hatalar şunlardır:

  • Redirect URI’yi Doğrulamamak: Saldırganlar, sahte redirect URI ekleyerek code injection yapabilir. Bu durum, kullanıcı hesabının tamamen ele geçirilmesine yol açar.
  • Client Secret’ı Front‑End’de Saklamak: Implicit grant dışındaki akışlarda client secret kesinlikle tarayıcıda bulunmamalıdır; aksi takdirde token çalınması riski %70’e kadar çıkabilir.
  • Scope’ları Gereksiz Şekilde Genişletmek: Gereksiz geniş scope’lar, uygulamanın saldırı yüzeyini artırır ve veri ihlali durumunda yasal sorumlulukları büyütür.
  • Token Süresini Uzun Ayarlamak: Access token’ın yaşam süresini 24 saat gibi uzun tutmak, çalındığında uzun süre geçerli kalacağı anlamına gelir; bu da potansiyel veri sızıntısının maliyetini katlar.

Bu hataların maliyeti, bir veri ihlali sonrası ortalama $3.86 milyon olarak raporlanmaktadır. Dolayısıyla, en iyi güvenlik uygulamalarını (HTTPS zorunluluğu, kısa token ömrü, revocation endpoint) benimsemek, uzun vadede çok daha ekonomik bir çözümdür.

Gerçek Dünya Senaryosu: OAuth 2.0 ile Çoklu Platform Entegrasyonu

Bir kurumsal hosting sağlayıcısının müşterileri, aynı kimlik bilgileriyle hem web paneline hem de mobil uygulamaya giriş yapabilmek istiyor. Çözüm, OAuth 2.0 Authorization Code Grant ve OpenID Connect kombinasyonudur.

İlk adımda, kimlik sağlayıcı (Identity Server) /authorize endpoint’i üzerinden bir authorization code üretir. Mobil uygulama, bu kodu sunucuya gönderdiğinde /token endpoint’i üzerinden hem access_token hem de id_token alır. id_token, JWT formatında olduğundan, mobil uygulama kullanıcıyı yerel olarak doğrulamak için imzayı kontrol eder; bu sayede ekstra bir network çağrısı yapmadan oturum açar.

Web paneli ise aynı kodu kullanarak sunucu tarafında token alır ve session oluşturur. Böylece, iki platform arasında tek bir oturum yönetimi sağlanır, kullanıcı deneyimi artar ve çift oturum açma sorunları %95 azaltılır. Ayrıca, token revocation endpoint’i sayesinde bir kullanıcı hesabı kapatıldığında tüm platformlarda oturum anında sonlandırılır.

Sıkça Sorulan Sorular

OAuth 2.0 ile JWT arasındaki fark nedir?

OAuth 2.0 bir yetkilendirme protokolüdür, token tipini (Bearer, MAC) belirler. JWT (JSON Web Token) ise token’ın içeriğini ve imzasını tanımlayan bir formattır; OAuth 2.0 içinde access token olarak kullanılabilir.

Refresh token ne zaman kullanılmalı?

Access token’ın süresi dolduğunda, kullanıcıyı tekrar oturum açmaya zorlamadan yeni bir token almak için refresh token kullanılır. Refresh token’lar genellikle uzun ömürlüdür ve güvenli bir şekilde saklanmalıdır.

Implicit grant hâlâ güvenli mi?

Implicit grant, tarayıcı tabanlı uygulamalarda token’ın URL fragment’inde döndürülmesi nedeniyle riskli kabul edilir. Modern SPA’ler için Authorization Code with PKCE önerilir; bu yöntem token çalınma riskini büyük ölçüde azaltır.

OAuth 2.0’ı kendi sunucumda nasıl host edebilirim?

OpenID Connect uyumlu bir kimlik sunucusu (ör. Keycloak, Auth0, Okta) AMD Ryzen VDS sunucular üzerinde kurularak tamamen kontrol edilebilir. Sunucuya SSL sertifikası eklemek, token endpoint’ini güvenli hâle getirir ve performans artışı sağlar.

Sonuç ve Bir Sonraki Adımınız

OAuth 2.0, modern uygulamaların güvenli kimlik doğrulama ve yetkilendirme ihtiyaçlarını karşılamak için evrimleşmiş bir protokoldür. Bu makalede gördüğünüz gibi, doğru akışı seçmek, token yaşam süresini yönetmek ve güvenli bir altyapı (HTTPS, VDS, proper scopes) kurmak, hem güvenlik risklerini azaltır hem de kullanıcı deneyimini iyileştirir.

Eğer henüz bir kimlik sunucusu kurmadıysanız, VDS sunucu paketleri üzerinden bir Linux tabanlı ortam oluşturup Keycloak gibi açık kaynak bir çözümle başlayabilirsiniz. İlk adımda Authorization Code Grant ve PKCE kombinasyonunu uygulayarak, uygulamanızın güvenliğini %50’ye varan bir oranda artırabilirsiniz.

Unutmayın, güvenlik bir kere yapılacak iş değil, sürekli izlenmesi ve güncellenmesi gereken bir süreçtir. OAuth 2.0 entegrasyonunuzu düzenli olarak test edin, revocation endpoint’ini aktif tutun ve token’ların süresini gerektiğinde yeniden ayarlayın. Böylece, hem kullanıcılarınızın verilerini korur hem de işletmenizin itibarını güvence altına alırsınız.