OAuth 2.0: nedir ve yetkilendirme protokolü nasıl çalışır

OAuth 2.0 Nedir?

OAuth 2.0, IETF RFC 6749'da tanımlanan, üçüncü taraf uygulamaların kullanıcının kullanıcı adını ve şifresini ifşa etmeden kaynaklarına sınırlı erişim elde etmesini sağlayan bir yetkilendirme protokolüdür. Protokol, şifre modelinin temel bir sorununu çözer: şifrenizi emanet ettiğiniz bir uygulama, tüm hesap verilerine sınırsız erişim elde eder. OAuth 2.0, açıkça sınırlandırılmış bir erişim kapsamına sahip geçici bir token yayınlayarak bu yaklaşımı değiştirir.

OAuth 2.0'ın mimarisi yetki devridir. Kullanıcı (Resource Owner), bir aracı olan yetkilendirme sunucusu (Authorization Server) aracılığıyla kaynak sunucusunda (Resource Server) depolanan verilerine erişmesi için bir uygulamayı (Client) yetkilendirir. Yetkilendirme sunucusu bir Access Token yayınlar: uygulamanın verilere erişmek için kaynak sunucusuna sunduğu kriptografik bir dize. OAuth 2.0 ile SAML veya OpenID Connect arasındaki önemli bir fark: OAuth 2.0 yetkilendirme görevini (neye izin verildiği) çözer, kimlik doğrulamayı (kullanıcının kim olduğu) değil. Kimlik doğrulama için OAuth 2.0 üzerinde OpenID Connect (OIDC) protokolü oluşturulmuştur.

Protokol tüm büyük platformlar tarafından desteklenmektedir. Google, Google API'lerine (Gmail, Drive, Calendar) erişmek için OAuth 2.0 kullanır, Facebook Graph API için, Apple Sign in with Apple (ASAuthorizationAppleIDProvider) için ve GitHub depo erişimi için kullanır. Mobil geliştirme bağlamında, OAuth 2.0 üçüncü taraf hizmetleri entegre etmek için standart mekanizmadır: sosyal ağlar üzerinden giriş, bulut depolamaya erişim ve kullanıcı adına içerik yayınlama.

OAuth 2.0 Rolleri ve Bileşenleri

OAuth 2.0 protokolü, etkileşimleri tam yetkilendirme döngüsünü oluşturan dört rol tanımlar. Mobil bir uygulamada protokolü doğru şekilde uygulamak için her rolü anlamak önemlidir.

Protokolün Dört Rolü

Protokolün temel varlıkları Access Token, Refresh Token ve Authorization Code'dur. Access Token, her veri talebinde kaynak sunucusuna sunulan kısa ömürlü bir tokendir (genellikle 15–60 dakika). Refresh Token, kullanıcının tekrar oturum açmasına gerek kalmadan yeni bir Access Token almak için kullanılan uzun ömürlü bir tokendir (günler veya haftalar). Authorization Code, kullanıcı yetkilendirmesinden sonra yayınlanan ve bir Access Token ve Refresh Token ile değiştirilen geçici bir koddur.

Grant Types: Yetkilendirme Senaryoları

OAuth 2.0, her biri belirli bir istemci türü ve güvenlik bağlamı için tasarlanmış çeşitli Grant Types (token alma senaryoları) tanımlar. Mobil bir uygulamada yetkilendirme tasarlarken doğru Grant Type'ı seçmek kritik bir mimari karardır.

Ana Grant Types şunlardır: Authorization Code (sunucu bileşeni olan mobil ve web uygulamaları için en güvenlisi), PKCE ile Authorization Code (Proof Key for Code Exchange: sunucu arka ucu olmayan mobil ve SPA uygulamaları için), Client Credentials (kullanıcı katılımı olmadan sunucudan sunucuya kimlik doğrulama için), Resource Owner Password Credentials (kullanımdan kaldırıldı: şifreyi doğrudan iletir). PKCE, OAuth Security BCP (RFC 9700) tavsiyelerine göre genel istemciler (mobil uygulamalar, SPA'lar) için zorunlu bir uzantıdır.

Ana Grant Types

• Authorization Code + PKCE, yerel mobil uygulamalar için önerilen Grant Type'dır. İstemci kriptografik bir code_verifier oluşturur, bir code_challenge (SHA-256 özeti) hesaplar ve sunucu, kodu bir token ile değiştirirken eşleşmeyi doğrular. Bu, uygulama ve sunucu arasında authorization code'un ele geçirilmesini önler
• Client Credentials, istemcinin bilindiği ve kimlik doğrulamasının yapıldığı makineden makineye yetkilendirme için kullanılır. Uygulama, client_id ve client_secret'ini kullanarak bir token alır. Kullanıcı katılımı gerekmez. Tipik senaryo: bir sunucu uygulamasının toplu veri işleme için bir API'yi çağırması
• Device Authorization Grant, tarayıcısı olmayan cihazlar (Smart TV, IoT) içindir. Kullanıcı başka bir cihazda bir bağlantıyı takip eder ve bir kod girer. Örneğin, bir akıllı telefon aracılığıyla televizyonda Netflix'i yetkilendirirken kullanılır
• Resource Owner Password Credentials, OAuth Security BCP tarafından yasaklanmış, kullanımdan kaldırılmış bir Grant Type'dır. Şifre doğrudan istemciye iletilir ve sıfır bilgi kimlik doğrulama ilkesini ihlal eder. Yalnızca eski sistemlerden geçiş için kullanılır

Mobil Uygulamalar İçin PKCE ile Authorization Code Flow

PKCE ile Authorization Code Flow, yerel mobil uygulamalar için önerilen OAuth 2.0 yapılandırmasıdır. PKCE (Proof Key for Code Exchange), authorization code ele geçirme saldırılarını önleyen ek bir koruma katmanı ekler. Protokol IETF RFC 7636'da açıklanmıştır.

PKCE Adım Adım Sıralaması

Adımların sıralaması: (1) istemci rastgele bir code_verifier oluşturur (yalnızca ayrılmamış karakterleri kullanan 43–128 karakterlik bir dize), (2) istemci code_challenge = SHA-256(code_verifier) hesaplar, (3) istemci, code_challenge'ı ileterek Authorization Server'da kullanıcı yetkilendirmesi için bir tarayıcı açar, (4) başarılı yetkilendirmeden sonra sunucu, özel bir URI şeması (uygulama derin bağlantısı) aracılığıyla authorization code'u uygulamaya döndürür, (5) istemci, authorization code + code_verifier'ı sunucuya gönderir, (6) sunucu SHA-256(code_verifier) === code_challenge'ı doğrular ve bir Access Token + Refresh Token yayınlar.

PKCE'nin avantajı: bir saldırgan URI şemasında authorization code'u ele geçirse bile, yalnızca meşru istemcinin bildiği code_verifier olmadan bunu bir token ile değiştiremez. Mobil uygulamalarda, tarayıcıyı açmak için Chrome Custom Tabs (Android) veya ASWebAuthenticationSession (iOS) kullanılmalıdır; bu, sistem tarayıcısının uygulamanın belleğinden code_verifier'a erişememesini sağlar.

AppAuth ile Android'de OAuth 2.0 Uygulaması

AppAuth, IETF tarafından önerilen, yerel uygulamalar için OAuth 2.0 ve OpenID Connect'in referans uygulamasıdır. Kütüphane PKCE, Chrome Custom Tabs, authorization code'u döndürmek için özel URI şemaları ve otomatik token yenilemeyi destekler. Android için AppAuth, `net.openid:appauth:0.11.1` bağımlılığı ile kullanılabilir.

val serviceConfig = AuthorizationServiceConfiguration.fromUrl(
    Uri.parse("https://accounts.google.com/.well-known/openid-configuration")
)

val request = AuthorizationRequest.Builder(
    serviceConfig,
    "CLIENT_ID.apps.googleusercontent.com",
    ResponseTypeValues.CODE,
    Uri.parse("com.example.app:/oauth2callback")
)
.setScope("openid profile email")
.setCodeVerifier(
    CodeVerifierUtil.generateRandomCodeVerifier()
)
.build()

val authService = AuthorizationService(context)
val intent = authService.getAuthorizationRequestIntent(request)

// Yetkilendirme için Chrome Custom Tab başlatma
startActivityForResult(intent, REQUEST_CODE_AUTH)

authorization code'u (onActivityResult) aldıktan sonra, uygulama bunu bir TokenRequest aracılığıyla Access Token ve Refresh Token ile değiştirir. Token'lar, EncryptedSharedPreferences (Android Security Crypto) aracılığıyla şifreleme ile SharedPreferences'te saklanır. Refresh Token, KeyStore'da (diğer uygulamaların erişemeyeceği donanım tabanlı bir anahtar deposu) saklanmalıdır. Access Token'ın süresi her dolduğunda, uygulama yenisini almak için Refresh Token'ı kullanır: kullanıcının yeniden kimlik doğrulaması yapması gerekmez.

// authorization code'u token'larla değiştirme
val data = intent?.data ?: return
val resp = AuthorizationResponse.fromIntent(data)
val exchangeReq = resp?.createTokenExchangeRequest()
    ?: return

authService.performTokenRequest(
    exchangeReq,
    ClientAuthentication.none()
) { tokenResp, ex ->
    if (tokenResp != null) {
        // Access Token ve Refresh Token alındı
        val accessToken = tokenResp.accessToken
        val refreshToken = tokenResp.refreshToken
        // EncryptedSharedPreferences'e kaydet
        saveTokens(accessToken, refreshToken)
    }
}

Yukarıdaki kod, PKCE ile tam OAuth 2.0 akışını göstermektedir: OpenID Connect Discovery aracılığıyla sunucu yapılandırması oluşturma, code_verifier ile yetkilendirme talebi oluşturma, Chrome Custom Tab başlatma, özel URI şeması aracılığıyla authorization code alma ve Token Request aracılığıyla kodun token'larla değiştirilmesi. Access Token süre sonunu işlemek önemlidir: Resource Server'dan HTTP 401 yanıtı alındığında, uygulama yeni bir Access Token almak için Refresh Token'ı kullanmalı ve talebi yeniden yürütmelidir.

OAuth 2.0 Güvenliği: Tipik Saldırılar ve Koruma

OAuth 2.0, birçok saldırı vektörüne sahip karmaşık bir protokoldür. IETF Security BCP (RFC 9700), OAuth 2.0 güvenlik açıklarının 20'den fazla sınıfını tanımlar. Mobil uygulamalar için en kritik olanlar: özel URI şemaları aracılığıyla authorization code ele geçirme, geri arama uç noktalarına CSRF saldırıları, güvenli olmayan depolamadan Refresh Token hırsızlığı ve intent ele geçirme yoluyla istemci kimliğine bürünmedir.

Bu saldırılara karşı koruma zorunlu önlemleri içerir: (1) S256 code_challenge ile PKCE: URI şeması ele geçirilse bile authorization code ele geçirmeyi önler; (2) CSRF'yi önlemek için nonce veya state parametresi kullanımı: sunucu, authorization code'un orijinal taleple eşleştiğini doğrular; (3) Refresh Token'ı yalnızca KeyStore'da (Android) veya Keychain'de (iOS) saklama: asla SharedPreferences veya UserDefaults'ta değil; (4) taşıma katmanında MITM'ye karşı koruma için Certificate Pinning ile TLS kullanımı; (5) redirect_uri doğrulaması: yetkilendirme sunucusu, kayıtlı URI ile eşleşmeyi sıkı bir şekilde doğrulamalıdır.

IETF'den ek tavsiyeler: mobil uygulamalar güvenlik denetimlerinden geçmiş AppAuth veya benzer kütüphaneleri kullanmalıdır; OAuth için WebView'a güvenmeyin (WebView, verileri ana uygulamadan ayırmaz); otomatik Refresh Token döndürme uygulayın (her Refresh Token yalnızca bir kez kullanılabilir); Android için TrustManager ve iOS için URLSession aracılığıyla Certificate Pinning ekleyin. OpenID Connect Discovery (well-known uç noktası), yetkilendirme sunucusunun doğru uç noktalarını otomatik olarak belirlemeye ve kimlik avı sayfalarına yönlendirmelerden kaçınmaya yardımcı olur.