OAuth Nedir?

Hangi sorunu çözer?

OAuth yaygınlaşmadan önce, bir uygulamanın örneğin takviminize erişebilmesi için e-posta hesabınızın parolasını o uygulamaya vermeniz gerekirdi. Bu, uygulamaya hesabınız üzerinde sınırsız ve geri alması zor bir yetki tanımak demekti. OAuth bu modeli tersine çevirir: kullanıcı yalnızca kendi hesap sağlayıcısına giriş yapar, uygulamaya hangi izinleri vereceğini onaylar ve uygulama yalnızca bu izinlerle sınırlı bir erişim token'ı alır. İzin, parolayı değiştirmeye gerek kalmadan tek tıkla geri alınabilir.

Dört rol

• Kaynak sahibi (resource owner): Çoğunlukla kullanıcının kendisi.
• İstemci (client): Erişim isteyen uygulama; web, mobil, masaüstü ya da başka bir servis olabilir.
• Yetkilendirme sunucusu (authorization server): Kullanıcıyı doğrulayan, onayını alan ve token üreten sunucu.
• Kaynak sunucusu (resource server): Korunan veriyi sunan API; gelen istekteki token'ı doğrular.

Authorization code + PKCE akışı

Kullanıcının dahil olduğu senaryolarda bugün önerilen yol, PKCE (RFC 7636) eklenmiş authorization code akışıdır. İstemci önce rastgele bir code_verifier üretir, bunun SHA-256 özetini code_challenge olarak kullanıcıyı yönlendirdiği adrese ekler:

GET /authorize?response_type=code
  &client_id=takvim-app
  &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
  &scope=calendar.read
  &state=af0ifjsldkj
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256

1. Kullanıcı yetkilendirme sunucusunda giriş yapar ve istenen kapsamı (calendar.read) onaylar.
2. Sunucu kullanıcıyı kısa ömürlü, tek kullanımlık bir code ile redirect_uri adresine geri gönderir. İstemci, dönen state değerinin kendi gönderdiğiyle aynı olduğunu kontrol eder.
3. İstemci bu kodu, ilk adımda ürettiği code_verifier ile birlikte token uç noktasına gönderir; karşılığında erişim token'ı ve gerekirse bir refresh token alır.
4. Sonraki API isteklerinde token, Authorization: Bearer ... başlığıyla gönderilir.

PKCE sayesinde yönlendirme sırasında kodu ele geçiren biri, code_verifier değerini bilmediği için onu token'a çeviremez. Bu yüzden tek sayfalık uygulamalar ve mobil uygulamalar gibi gizli anahtar saklayamayan istemcilerde PKCE fiilen zorunludur; OAuth 2.0 güvenlik rehberi (RFC 9700) gizli anahtarı olan sunucu tarafı istemcilerde de kullanılmasını önerir.

Diğer akışlar

Ortada kullanıcı olmadan iki servisin konuştuğu durumlarda client credentials akışı kullanılır. Klavyesi olmayan cihazlar (akıllı TV, konsol) için device authorization akışı vardır. Eski implicit akışı ve kullanıcının parolasını doğrudan istemciye veren resource owner password credentials akışı ise güncel güvenlik önerilerine göre artık kullanılmamalıdır.

OAuth ve OpenID Connect

En yaygın yanılgı OAuth'u bir giriş protokolü sanmaktır. Erişim token'ı kaynak sunucusu için üretilir; istemciye "bu kullanıcı kim ve nasıl doğrulandı" bilgisini güvenilir biçimde vermez. Bu boşluğu OpenID Connect (OIDC) doldurur: openid kapsamı istendiğinde yetkilendirme sunucusu, erişim token'ının yanında istemciye yönelik, imzalı bir ID token da döndürür. ID token bir JWT'dir ve kullanıcının kimliğini ve doğrulama bilgilerini taşır. "Google ile giriş yap" düğmeleri bu yüzden çıplak OAuth değil, OIDC örnekleridir. Kısaca OAuth yetkilendirme, OIDC ise kimlik doğrulama içindir.

Entegrasyonda sık yapılan hatalar

• redirect_uri değerini joker karakter ya da kısmi eşleşmeyle kabul etmek; kayıtlı adresle birebir eşleşmelidir.
• state parametresini atlayarak CSRF saldırılarına kapı açmak.
• Gereğinden geniş kapsam istemek: takvimi yalnızca okuyacak bir uygulama yazma izni istememelidir.
• Erişim token'ını kullanıcının kimliğinin kanıtı gibi kullanmak; giriş için ID token doğrulanmalıdır.
• Refresh token'ları güvensiz yerde saklamak; uzun ömürlü oldukları için erişim token'ından daha değerlidirler.