OAuth 2.0 Nedir? 30 Dakikada Güvenli Yetkilendirme

Meta Description

OAuth 2.0 nedir ve nasıl uygulanır? PKCE, scope ve token yönetimiyle güvenli yetkilendirmeyi 30 dakikada kurun. Hemen deneyin.

Giriş (Introduction)

Bir kullanıcı “Google ile giriş yap” dediğinde aslında şunu bekler: şifresini sizinle paylaşmadan, güvenli şekilde giriş yapabilmek. Siz ise şunu istersiniz: Kullanıcının verisine sadece izin verdiği kadar erişmek ve bunu denetlenebilir şekilde yönetmek.

İşte tam bu noktada OAuth 2.0 devreye girer. OAuth 2.0, kimlik doğrulamadan (authentication) çok yetkilendirme (authorization) problemine çözüm getirir: “Bu uygulama, bu kullanıcı adına, şu kaynaklara erişebilir mi?”

Bu yazıda OAuth 2.0’ı “kavramsal ama pratik” ele alacağız. Akışları (flows), scope mantığını, PKCE’yi ve token yönetimini anlayıp, gerçek hayatta en çok işinize yarayan düzeni kuracaksınız.

---

OAuth 2.0 Nedir? (Anahtar kelime: OAuth 2.0)

OAuth 2.0, bir uygulamanın (client) kullanıcı adına bir kaynağa (resource) erişmesi için, kullanıcıdan izin almasını ve bu izni access token üzerinden kanıtlamasını sağlayan standarttır.

OAuth 2.0 size şu avantajları sağlar:

• Kullanıcı parolasını uygulamanızla paylaşmaz
• İzinleri scope ile sınırlandırırsınız (en az ayrıcalık)
• Token’ları iptal edebilir, süreli yapabilir, yenileyebilirsiniz
• 1. parti entegrasyonlarda (Google, GitHub, Microsoft vb.) endüstri standardıdır

Bunu neden yapmalıyım? Çünkü “şifre saklama” riskini üzerinizden alır ve entegrasyonlarınızı güvenli, ölçeklenebilir ve denetlenebilir hale getirir.

---

Temel Kavramlar: Kim Kimdir?

OAuth 2.0’ı hızlı anlamanın yolu rolleri netleştirmektir:

Terim	Ne demek?	Örnek
Resource Owner	Kaynağın sahibi	Kullanıcı
Client	Erişim isteyen uygulama	Web app / mobil app
Authorization Server	Token veren otorite	Google OAuth sunucusu / sizin auth sunucunuz
Resource Server	API/kaynak sunucusu	api.sirket.com
Access Token	API çağrılarında kullanılan token	Bearer eyJ...
Refresh Token	Access token bitince yenilemeye yarar	Uzun ömürlü token

LSI anahtar kelimeler: access token, refresh token, scope, authorization code, PKCE, bearer token, token yenileme.

---

OAuth 2.0 Akışları (Flows): Hangisini Ne Zaman Seçmeliyim?

OAuth 2.0’da “tek yol” yoktur. Uygulamanın türüne göre akış seçersiniz.

Authorization Code Flow (En yaygın)

Web uygulamalarında ve server-side sistemlerde en sık kullanılan yöntemdir.

Genel fikir:

1. Kullanıcı provider’ın giriş/izin ekranına gider
2. Başarılı olursa provider sizin callback URL’nize authorization code döner
3. Siz bu code’u backend’den provider’a verip access token alırsınız

Ne zaman? Backend’i olan web uygulamalarında.

Authorization Code + PKCE (SPA ve mobil için “modern” standart)

SPA (React/Vue) veya mobil uygulamada client secret saklayamazsınız. Bu yüzden PKCE (Proof Key for Code Exchange) kullanılır.

PKCE ne sağlar?

• Code ele geçirilse bile token’a çevrilemez (code verifier olmadan)

Ne zaman? Mobil uygulama, SPA, public client.

Client Credentials Flow (Makine-makine)

Kullanıcı yoktur. Servisler birbirine erişir.

Ne zaman? Cron job, arka plan servisleri, servis-to-servis API erişimi.

---

Scope ve Consent: “Ne Kadar İzin” Meselesi

OAuth 2.0’ın en kritik kısmı scope tasarımıdır. Scope, client’ın hangi işlemleri yapabileceğini belirler.

İyi scope tasarımı için kısa checklist:

• Scope’ları okuma/yazma ayırın: orders:read, orders:write
• Çok geniş scope vermeyin: admin:all gibi “god scope”lardan kaçının
• Consent ekranında kullanıcıya net anlatın

Örnek scope seti:

• profile:read
• email:read
• orders:read
• orders:write

Bunu neden yapmalıyım? Scope’lar, veri sızıntısı riskini azaltır ve güvenlik incelemelerinde (pentest/ISO) elinizi güçlendirir.

---

Token Yönetimi: Access Token, Refresh Token, Expiry

OAuth 2.0 uygulamalarında en çok hata token yaşam döngüsünde yapılır.

Access Token

• Kısa ömürlü olmalı (ör. 5–15 dk)
• API çağrılarında Authorization: Bearer <token> olarak gönderilir

Refresh Token

• Daha uzun ömürlüdür (gün/hafta)
• Sadece güvenli ortamlarda saklanmalı (server-side)
• Refresh token sızarsa, saldırgan sürekli token yenileyebilir

Pratik öneriler

• Refresh token’ları rotate edin (her yenilemede yenisini verip eskisini iptal edin)
• Token iptali (revocation) endpoint’i planlayın
• aud, iss, exp gibi claim kontrollerini uygulayın (özellikle JWT kullanıyorsanız)

---

Adım Adım: OAuth 2.0 Authorization Code + PKCE Mantığı

Bu bölüm “akışı kafada oturtmak” için.

1) Code Verifier üret

Client tarafında rastgele, yüksek entropili bir string üretirsiniz.

2) Code Challenge türet

S256 ile code_verifier hash’lenip base64url yapılır.

3) Authorization isteği

Kullanıcıyı şu tip URL’ye yönlendirirsiniz:

• response_type=code
• client_id=...
• redirect_uri=...
• scope=...
• code_challenge=...
• code_challenge_method=S256

4) Callback ile code gelir

Provider, redirect_uri’a ?code=... döner.

5) Token alma (code + verifier)

Backend veya güvenli ortamdan token endpoint’ine istek atarsınız:

• grant_type=authorization_code
• code=...
• code_verifier=...

Bunu neden yapmalıyım? SPA/mobil uygulamalarda “secret saklama” problemi yüzünden en güvenli yaklaşım budur.

---

Node.js ile Mini Örnek: Token ile API Çağrısı

Aşağıda örnek olarak, elinizde bir access token varken API çağrısı yapmayı gösteriyorum (provider bağımsız).

// node >= 18
// ACCESS_TOKEN'ı OAuth 2.0 sağlayıcınızdan aldığınızı varsayalım

const ACCESS_TOKEN = process.env.ACCESS_TOKEN;

async function callApi() {
  const res = await fetch("https://api.example.com/v1/orders", {
    headers: {
      Authorization: `Bearer ${ACCESS_TOKEN}`,
      "Content-Type": "application/json",
    },
  });

  if (!res.ok) {
    const text = await res.text();
    throw new Error(`API hata: ${res.status} - ${text}`);
  }

  const data = await res.json();
  console.log("Orders:", data);
}

callApi().catch(console.error);

Gerçek hayatta burada kritik olanlar:

• Token’ı log’a basmamak
• Token süresi bitince 401/403 durumunda yenileme stratejisi
• İsteklerinizi scope’lara göre ayırmak

---

Gerçek Hayat Senaryosu: “Google ile Giriş”te Ne Oluyor?

Bir SaaS ürününüz var ve kullanıcı “Google ile giriş”e tıklıyor:

1. Siz kullanıcıyı Google consent ekranına yönlendiriyorsunuz
2. Google, kullanıcıdan e-posta/profil gibi izinler istiyor (scope)
3. Kullanıcı onaylıyor
4. Siz bir code alıyorsunuz
5. Bu code’u token ile değiştiriyorsunuz
6. Access token ile /userinfo gibi endpoint’ten kullanıcı bilgisi çekiyorsunuz

Buradaki püf nokta: Siz kullanıcı şifresini hiç görmüyorsunuz.

---

Sık Sorulan Sorular (FAQ)

1) OAuth 2.0 kimlik doğrulama mı, yetkilendirme mi?

OAuth 2.0 temel olarak yetkilendirme standardıdır. Kimlik doğrulama için genelde OpenID Connect (OIDC) kullanılır.

2) PKCE kullanmak zorunda mıyım?

SPA ve mobil uygulamalarda evet, güçlü şekilde önerilir. Client secret saklayamadığınız için PKCE güvenlik katmanı sağlar.

3) Access token ile refresh token farkı nedir?

Access token kısa ömürlüdür ve API çağrısında kullanılır. Refresh token access token bitince yenisini almak içindir ve daha sıkı korunmalıdır.

4) Scope’ları nasıl belirlemeliyim?

En iyi yaklaşım en az ayrıcalık (least privilege): sadece gereken izinleri verin, okuma/yazmayı ayırın ve kapsamı dar tutun.

5) OAuth 2.0 kullanınca %100 güvenli olur muyum?

Hayır. Yanlış redirect URI yönetimi, token sızıntısı, zayıf scope tasarımı gibi hatalar hâlâ risk yaratır. Doğru implementasyon şarttır.

---

Sonuç

OAuth 2.0, kullanıcı şifresiyle uğraşmadan güvenli yetkilendirme yapmanızı sağlar. Bu yazıda OAuth 2.0’ın rollerini, akışlarını, PKCE mantığını, scope tasarımını ve token yönetiminin pratik kurallarını öğrendiniz.

Sıradaki adım: Kullandığınız senaryoyu seçin (SPA/mobil için Authorization Code + PKCE, servisler arası için Client Credentials) ve kendi uygulamanızda küçük bir PoC çıkarın.

Yorumlarda şunu yazın: Hangi sağlayıcıyla (Google, GitHub, Microsoft, kendi auth sunucunuz) OAuth 2.0 kuruyorsunuz ve en çok nerede takıldınız? İsterseniz akışınıza göre örnek redirect/token URL şemasını birlikte netleştirelim.