OAuth 2.0 Authentication | Burak Demiröz

OAuth Nedir?

OAuth (Open Authorization), web sitelerinin ve web uygulamalarının, kullanıcının başka bir uygulamadaki hesabına sınırlı erişim talep etmesini sağlayan yaygın olarak kullanılan bir yetkilendirme framework'üdür. OAuth, kullanıcının giriş kimlik bilgilerini talep eden uygulamaya ifşa etmeden bu erişimi sağlamasına olanak tanır.

OAuth 2.0, kullanıcıların hangi verileri paylaşmak istediklerini tam kontrollerinde tutarak, üçüncü taraf uygulamalarına hesaplarının tam kontrolünü vermek zorunda kalmamalarını sağlar.

💡 Tarihçe: OAuth 2.0 mevcut standart olmasına rağmen, bazı web siteleri hala legacy sürüm 1a kullanmaktadır. OAuth 2.0, OAuth 1.0'dan doğrudan geliştirilmek yerine sıfırdan yazılmıştır.

OAuth'un Temel Avantajları:

• Kullanıcı kimlik bilgilerini paylaşmaya gerek yok
• Sınırlı ve kontrollü veri erişimi
• Üçüncü taraf entegrasyonları için güvenli
• Yaygın sosyal medya girişleri
• Tek oturum açma (SSO) desteği

OAuth Aktörleri

Client Application: Kullanıcının verilerine erişmek isteyen web sitesi
Resource Owner: Verilerine erişilmek istenen kullanıcı
OAuth Service Provider: Kullanıcı verilerini kontrol eden servis sağlayıcı

OAuth 2.0 Nasıl Çalışır?

OAuth 2.0, üç farklı taraf arasında tanımlanmış bir dizi etkileşim aracılığıyla çalışır. Çeşitli OAuth "flows" veya "grant types" mevcuttur. Bu bölümde en yaygın kullanılan "authorization code" ve "implicit" grant türlerine odaklanacağız.

1. İstemci Uygulaması Erişim Talebi

2. Kullanıcı Girişi ve Onay

3. Access Token Alımı

4. API Çağrıları

Authorization Code Grant Type

En güvenli OAuth flow türüdür. Access token, güvenli bir back-channel üzerinden alınır.

GET /authorization?client_id=12345&redirect_uri=https://client-app.com/callback&response_type=code&scope=openid%20profile&state=ae13d489bd00e3c24 HTTP/1.1
Host: oauth-authorization-server.com
                    

Implicit Grant Type

Single-page uygulamalar için geliştirilmiş, ancak daha az güvenli olan flow türüdür.

Implicit flow örneği: GET /authorization?client_id=12345&redirect_uri=https://client-app.com/callback&response_type=token&scope=openid%20profile&state=ae13d489bd00e3c24 HTTP/1.1 Host: oauth-authorization-server.com

Güvenlik Uyarısı: Implicit grant type, access token'ı URL fragment olarak tarayıcı üzerinden gönderdiği için daha az güvenlidir ve çeşitli saldırılara açıktır.

OAuth ile Kimlik Doğrulama

OAuth orijinal olarak bu amaçla tasarlanmamış olsa da, kullanıcı kimlik doğrulaması için de bir araç haline gelmiştir. Sosyal medya hesabınızla giriş yapma seçeneği gören birçok web sitesi OAuth 2.0 kullanır.

OAuth Authentication Süreci

1. Kullanıcı sosyal medya hesabıyla giriş yapmayı seçer
2. İstemci uygulama, kullanıcıyı tanımlamak için veri talep eder
3. Access token alındıktan sonra, /userinfo endpoint'inden veri çekilir
4. Alınan veri kullanıcı adı yerine kullanılarak giriş sağlanır

OAuth Authentication'ın SAML ile Benzerliği:
Son kullanıcı perspektifinden OAuth authentication, SAML tabanlı Single Sign-On (SSO) deneyimine benzer bir sonuç üretir.

POST /userinfo HTTP/1.1
Host: oauth-resource-server.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Response:
{
  "sub": "12345",
  "name": "John Doe",
  "email": "john@example.com"
}
                    

OAuth Güvenlik Açıkları Nasıl Ortaya Çıkar?

OAuth güvenlik açıkları kısmen OAuth spesifikasyonunun tasarımı gereği nispeten belirsiz ve esnek olmasından kaynaklanır. Temel işlevsellik için zorunlu bileşenler mevcut olsa da, implementasyonun büyük çoğunluğu tamamen isteğe bağlıdır.

Temel Problem Alanları:
• Esnek ve belirsiz spesifikasyon
• Built-in güvenlik özelliklerinin eksikliği
• Hassas verilerin tarayıcı üzerinden gönderilmesi
• Konfigürasyon hatalarına açık yapı
• Yetersiz input validation

OAuth Authentication'ı Tanımlama

OAuth kullanımını tespit etmek için Burp Suite gibi proxy araçları kullanarak HTTP trafiğini inceleyebilirsiniz. İlk authorization request'i her zaman /authorization endpoint'ine yapılır ve client_id, redirect_uri, response_type parametrelerini içerir.

💡 Recon İpuçları:
Standard endpoint'leri kontrol edin:
• /.well-known/oauth-authorization-server
• /.well-known/openid-configuration
Bu endpoint'ler genellikle yapılandırma bilgilerini içeren JSON dosyalar döndürür.

İstemci Uygulaması Güvenlik Açıkları

İstemci uygulamalar genellikle güvenilir OAuth servisleri kullanır, ancak kendi implementasyonları güvenlik açıkları içerebilir. OAuth spesifikasyonunun gevşek tanımlaması, özellikle istemci uygulaması implementasyonunda çeşitli yanlış konfigürasyonlara yol açabilir.

İstemci Tarafı Ana Güvenlik Açığı Kategorileri:

• Implicit grant type'ın yanlış implementasyonu
• Kusurlu CSRF koruması
• Yetersiz token doğrulama
• State parametresi eksikliği
• Redirect URI doğrulama problemleri

Implicit Grant Type'ın Yanlış Implementasyonu

Implicit grant type, tarayıcı üzerinden access token göndermenin getirdiği tehlikeler nedeniyle esas olarak single-page uygulamalar için önerilir. Ancak göreli basitliği nedeniyle klasik client-server web uygulamalarında da sık kullanılır.

OAuth Service

Browser (URL Fragment)

Client App (JavaScript)

Server (POST Request)

Güvenlik Açığı:
İstemci uygulaması, access token'ın request'teki diğer verilerle eşleşip eşleşmediğini kontrol etmezse, saldırgan parametreleri değiştirerek herhangi bir kullanıcıyı taklit edebilir.

POST /authenticate HTTP/1.1
Host: vulnerable-app.com
Content-Type: application/x-www-form-urlencoded

access_token=stolen_token_here&email=victim@example.com&username=victim
                    

Saldırı Senaryosu: 1. Saldırgan kendi OAuth akışını başlatır 2. Kendi access token'ını alır 3. POST request'te email ve username parametrelerini kurbanın bilgileriyle değiştirir 4. Sunucu token doğrulaması yapmadan kurban kullanıcı olarak giriş sağlar

Kusurlu CSRF Koruması

OAuth flow'larının birçok bileşeni isteğe bağlı olsa da, bazıları güçlü bir şekilde önerilir. Bunlardan biri state parametresidir. State parametresi, kullanıcının oturumuna bağlı tahmin edilemez bir değer içermeli ve OAuth akışı boyunca CSRF token görevi görmelidir.

State Parametresi Eksikliği:
Authorization request'inde state parametresi gönderilmiyorsa, saldırgan kendi OAuth akışını başlatıp kurbanın tarayıcısını bu akışı tamamlaması için kandırabilir.

# Güvenli OAuth Request (state parametresi ile):
GET /authorization?client_id=123&redirect_uri=https://app.com/callback&response_type=code&state=unguessable_random_value

# Güvensiz OAuth Request (state parametresi yok):
GET /authorization?client_id=123&redirect_uri=https://app.com/callback&response_type=code
                    

Forced OAuth Profile Linking

Kullanıcıların hem şifre hem de OAuth ile giriş yapabildiği sitelerde, state parametresi eksikliği kurban kullanıcının hesabını saldırganın sosyal medya hesabına bağlamaya yol açabilir.

💡 Login CSRF:
Sadece OAuth ile giriş yapılan sitelerde bile state parametresi eksikliği, kullanıcıyı saldırganın hesabına giriş yapmaya zorlayan login CSRF saldırılarına yol açabilir.

OAuth Servis Güvenlik Açıkları

OAuth servisi konfigürasyonundaki güvenlik açıkları, saldırganların diğer kullanıcılara ait authorization code'ları veya access token'ları çalmasına olanak sağlayabilir. Bu durum hesap ele geçirme saldırılarına yol açar.

OAuth Servis Açığı Kategorileri:

• Authorization code ve access token sızması
• Kusurlu scope doğrulama
• Doğrulanmamış kullanıcı kaydı
• Redirect URI doğrulama problemleri
• Flawed client authentication

Authorization Code ve Access Token Sızması

OAuth tabanlı en ünlü güvenlik açığı, OAuth servisinin konfigürasyonunun saldırganların diğer kullanıcıların authorization code'larını veya access token'larını çalmasına olanak sağlamasıdır.

Saldırı Mekanizması:
OAuth servisi redirect_uri parametresini düzgün doğrulamazsa, saldırgan CSRF benzeri saldırı ile kurbanın tarayıcısını saldırgan kontrollü redirect_uri'ye code/token göndermesi için kandırabilir.

# Orijinal legitimate request:
GET /authorization?client_id=123&redirect_uri=https://client-app.com/callback&response_type=code

# Saldırgan tarafından modifiye edilmiş request:
GET /authorization?client_id=123&redirect_uri=https://evil-attacker.net/callback&response_type=code
                    

Authorization Code Flow Saldırısı: 1. Saldırgan kurbanı kötü niyetli link'e yönlendirir 2. Kurban OAuth servisiyle geçerli oturumu varsa authorization code saldırgana gönderilir 3. Saldırgan bu code'u legitimate callback endpoint'ine gönderir 4. Client application, saldırgan adına code/token exchange işlemini tamamlar 5. Saldırgan kurban kullanıcı olarak giriş yapar

💡 Önemli Not:
State veya nonce koruması bu saldırıları mutlaka önlemez çünkü saldırgan kendi tarayıcısından yeni değerler üretebilir.

Kusurlu Redirect URI Doğrulama

Güvenli OAuth servisler, client uygulamaları kayıt sırasında legitimate callback URI'lerinin whitelist'ini ister. Yeni request geldiğinde redirect_uri bu whitelist'e karşı doğrulanır. Ancak bu doğrulama bypass edilebilir.

Bypass Teknikleri

Path Traversal: https://client-app.com/oauth/callback/../../evil/path
Subdomain Bypass: https://evil.client-app.com
Parameter Pollution: Çoklu redirect_uri parametresi
Fragment/Query Bypass: URL parsing farklılıkları

# Çeşitli bypass denemeleri:
redirect_uri=https://client-app.com/callback/../../admin
redirect_uri=https://client-app.com@evil-attacker.net
redirect_uri=https://localhost.evil-attacker.net
redirect_uri=https://client-app.com?evil=attacker.net
redirect_uri=https://client-app.com#@evil-attacker.net
                    

Localhost Bypass:
Development amaçlı localhost URI'leri production ortamında bazen yanlışlıkla kabul edilir. localhost.evil-attacker.net gibi domain kayıtları bu durumu istismar edebilir.

Proxy Page ile Code/Token Çalma

External domain submit edilemiyorsa, whitelist'teki domain içinde başka sayfalara yönlendirme mümkün mü kontrol edilmelidir.

Proxy Page Saldırı Zinciri: 1. Vulnerable redirect URI bulma: /oauth/callback/../../profile 2. Bu sayfada open redirect bulma 3. Open redirect ile external domain'e yönlendirme 4. External domain'de JavaScript ile code/token extraction 5. Saldırgan sunucusuna token gönderme

Token Çalmada Kullanılabilecek Güvenlik Açıkları:
• Open Redirect
• XSS (Cross-Site Scripting)
• HTML Injection
• Dangerous JavaScript handling
• Insecure web messaging

Kusurlu Scope Doğrulama

OAuth flow'da kullanıcı, authorization request'te tanımlanan scope'a göre erişim onayı verir. Ancak bazen saldırganlar "scope upgrade" yaparak access token'ına ek izinler ekleyebilir.

Authorization Code Flow'da Scope Upgrade

# Original authorization request:
scope=openid%20email

# Token exchange request (saldırgan tarafından modifiye):
POST /token
Host: oauth-server.com
Content-Type: application/x-www-form-urlencoded

client_id=123&client_secret=SECRET&grant_type=authorization_code&code=abc123&scope=openid%20email%20profile
                    

Scope Upgrade Saldırısı: 1. Saldırgan kendi malicious client uygulaması kaydeder 2. Kullanıcıdan sadece email iznini ister 3. Authorization code alındıktan sonra code/token exchange'de profile scope'unu ekler 4. Server doğrulama yapmıyorsa genişletilmiş izinlerle token üretir

Implicit Flow'da Scope Upgrade

# Çalınan access token ile manual request:
GET /userinfo?scope=openid%20email%20profile HTTP/1.1
Host: oauth-resource-server.com
Authorization: Bearer stolen_access_token
                    

Risk: OAuth servisi scope değerini token üretilirken kullanılan scope'a karşı doğrulamazsa, saldırgan kullanıcıdan daha fazla izin almadan ek verilere erişebilir.

OpenID Connect ile OAuth Genişletmesi

Authentication için kullanıldığında OAuth genellikle OpenID Connect katmanı ile genişletilir. Bu katman, kullanıcıları tanımlama ve authenticate etme ile ilgili ek özellikler sağlar.

OpenID Connect Özellikleri:
• ID Token (JWT format)
• UserInfo Endpoint
• Standardized claims
• Discovery mechanism
• Session management

# OpenID Connect ID Token örneği:
{
  "iss": "https://oauth-server.com",
  "sub": "12345",
  "aud": "client-app-id",
  "exp": 1640995200,
  "iat": 1640991600,
  "email": "user@example.com",
  "email_verified": true,
  "name": "John Doe"
}
                    

JWT Token Doğrulama

OpenID Connect'te ID token'lar JWT formatında gelir ve kriptografik olarak imzalanır. Client uygulamalar bu imzayı doğrulamak zorundadır.

💡 Discovery Endpoint:
/.well-known/openid-configuration endpoint'i OpenID Connect provider'ın desteklediği tüm özellikleri listeler ve attack surface'i genişletebilir.

OAuth Authentication Güvenlik Açıklarını Önleme

OAuth authentication güvenlik açıklarını önlemek için hem client uygulaması hem de OAuth service provider tarafında çeşitli güvenlik önlemleri alınmalıdır.

Client Application İçin Öneriler:

• Her zaman state parametresi kullanın
• Access token'ları güvenli şekilde saklayın
• Redirect URI'leri whitelist ile sınırlandırın
• HTTPS kullanımını zorunlu kılın
• Token doğrulama işlemlerini server-side yapın
• Implicit flow yerine authorization code flow tercih edin

💡 OAuth Service Provider İçin:
• Redirect URI'leri sıkı şekilde doğrulayın
• Scope validation işlemlerini yapın
• Rate limiting uygulayın
• Authorization code'ları kısa süreli yapın
• PKCE (Proof Key for Code Exchange) kullanın

En Kritik Güvenlik Önlemleri:
1. State parametresi mutlaka kullanılmalı
2. Redirect URI strict validation
3. HTTPS-only communication
4. Token expiration ve rotation
5. Proper scope validation

Test Araçları

Burp Suite: OAuth flow'ları analiz etmek için
OWASP ZAP: Automated security scanning
OAuth Security Scanner: Specialized OAuth testing
JWT.io: JWT token analysis

# Güvenli OAuth Implementation örneği:
POST /token HTTP/1.1
Host: secure-oauth-server.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=abc123&
redirect_uri=https://app.com/callback&
client_id=123&
client_secret=SECRET&
code_verifier=random_string_for_pkce
                    

OAuth 2.0 Authentication Özeti

Temel Güvenlik Kontrolleri

State Parameter: CSRF koruması için zorunlu
Redirect URI Validation: Whitelist tabanlı sıkı kontrol
Scope Validation: Token-scope eşleştirmesi
Token Security: Güvenli saklama ve transmission
HTTPS Enforcement: Tüm OAuth komunikasyonu için
Authorization Code: Implicit flow yerine tercih edilmeli

"Security is not a product, but a process." - Bruce Schneier