Herkes İçin , Her Yerde Bilgi

Modern web uygulamalarında, farklı servislerin,sistemlerin birbirleriyle güvenli bir şekilde iletişim kurması kritik bir öneme sahiptir. Bir hizmeti kullanırken , ilgili sistemde oturum açtıktan sonra, başka bir sistemdeki verilere de erişim sağlamamız gereken durumlar olabilir. Online fotoğraf baskı hizmeti sunan bir firmamızın olduğunu düşünelim, müşterilerimiz sistemimize girdikten sonra , fotoğraflarını seçmek için Google Drive'daki fotoğraflarına erişmek isteyebilir . Bunun gibi senaryolarda OAuth 2.0 protokolü yardımcı bir protokol olarak karşımıza çıkmaktadır.

OAuth 2.0, servisler arası yetkilendirme (authorization) için tasarlanmış bir standarttır. Makalemizde, OAuth 2.0'ın temel kavramlarını ve önemli yetkilendirme akışlarını detaylı bir şekilde inceleyeceğiz.

OAuth 2.0 Nedir?

OAuth ismindeki "Auth" kelimesi çoğu zaman authentication (kimlik doğrulama) ile karıştırılır, ancak buradaki "auth" authorization (yetkilendirme) anlamına gelir. OAuth 2.0, bir servisin başka bir servise erişim yetkisi vermesi için tasarlanmıştır - bir kullanıcının, kimliğini doğrulamak için kullanılmamaktadır.

OAuth başlangıçta bir servisin bir kişiyi yetkilendirmesi için değil, bir servisin başka bir servisi yetkilendirmesi için oluşturulmuştur. Peki neden bir servis başka bir servisi yetkilendirsin? Bu sorunun cevabını klasik bir örnekle açıklayalım.

Fotoğraf Baskı sistemi analojisi üzerinden OAuth

Bir fotoğraf baskı hizmeti sunan web sitesi düşünelim.
Kullanıcılar sisteme fotoğraf yükleyerek baskı siparişi verebiliyor. Ancak her kullanıcının fotoğraflarını tek tek bilgisayarından yüklemesi hem kullanıcı deneyimini zorlaştırıyor, hem altyapı maliyetini artırıyor, hem de güvenlik riskleri doğuruyor.

Günümüzde kullanıcıların büyük bir kısmı fotoğraflarını artık yerel bilgisayarlarda değil, Google Drive gibi bulut servislerinde saklıyor. Bu noktada kullanıcı şu soruyu soruyor:

“Google Drive’daki fotoğraflarımı doğrudan içe aktarabilir miyim?”

Böyle bir özellik kullanıcı için büyük bir kolaylık sağlar. Ancak burada da kritik bir problem vardır:

Google Drive’daki dosyalar Google tarafından korunmaktadır ve bu dosyalara erişim için Google kimlik doğrulaması gereklidir.

Peki web sitemiz, kullanıcının Google kullanıcı adı ve şifresini istemeden, kullanıcı adına Google Drive’daki fotoğraflara nasıl erişebilir?

Yanlış Yaklaşım: Kullanıcı Kimlik Bilgilerini İstemek

Teoride: kullanıcıdan Google ID ve şifresini isteyerek bu süreci gerçekleştirebileceğimizi düşünebiliriz.Fakat kullanıcıların bu secret bilgileri paylaşmayacağını düşündüğümüzde , bu fikrin teorinin ötesine geçemeyeceğini rahatlıkla söyleyebiliriz.

Vale - Anahtar Analojisi

OAuth'u anlamak için çok yaygın kullanılan bir analoji vardır: vale - anahtar modeli. Bir araç sahibi otoparka gelir, arabadan iner ve anahtarı vale'ye verir, aracını park etmesini rica eder. Vale anahtarı alır, arabayı park yerine çeker ve park eder.

Ancak bazı araç sahiplerinin vale'ye anahtar teslimi yaparken endişesi olabilir. :) Arabanın bagajina koyduğu veya torpidosuna koyduğu kıymetli bir eşyasının gidebileceğini düşünebilir veya aracının başka bir yere götürülebileceğini...

Bazı arabalar, bu tarz durumlarda kullanmak üzere, ek bir anahtar ile gelir: valet anahtar. Valet anahtar, ana araba anahtarı gibidir ama sınırlı erişime sahiptir:

• Arabayı çalıştırabilir ve durdurabilir

• Bagajı veya torpido gözünü açamaz

• Yakıt deposunu açamaz

Araç sahibi böyle bir anahtara sahipse, vale'ye vermek konusunda daha rahat olur , vale'nin bu anahtarla amaçlanan işinin dışında bir şey yapamayacağını bilir.

OAuth bu şekilde çalışır: ilgili sisteme -tam kimlik bilgileri yerine ,sınırlı erişim sağlayan- bir 'valet anahtar' (access token) verilir.

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

Fotoğraf baskı hizmeti sunan web uygulamasında, kullanıcıların Google Drive hesaplarındaki görsellere doğrudan erişebilmek önemli bir kullanım kolaylığı sağlar. Ancak bu senaryoda bir güven problemi ortaya çıkar:

Kullanıcı hem fotoğraf baskı servisine hem de Google hesabına giriş yapmış olsa da, bu iki sistem birbirlerine doğrudan güvenmez. Her sistem yalnızca kullanıcıyı tanır ve doğrular; üçüncü taraf bir servisin, kullanıcı adına işlem yapabilmesi için ek bir yetkilendirme mekanizmasına ihtiyaç vardır.

Bu noktada, fotoğraf baskı servisinin Google’a doğrudan “kullanıcının dosyalarına erişmek istiyorum” talebinde bulunması yeterli değildir. Google açısından bu talep, kimliği ve yetkisi doğrulanmamış bir üçüncü taraf isteği olarak değerlendirilir ve reddedilir. Google, kullanıcı verilerine erişim konusunda yalnızca kullanıcının açık onayına dayalı işlemleri kabul eder.

OAuth protokolü bu güven problemini çözmek üzere tasarlanmıştır. OAuth kullanan bir sistemde, üçüncü taraf servisler (bu örnekte fotoğraf baskı servisi) kullanıcı adına doğrudan veri talep etmek yerine, yetkilendirme sürecini kullanıcının kendisine yönlendirir.

Bu akışta şu adımlar gerçekleşir:

1-Fotoğraf baskı servisi, Google’a kullanıcının dosyalarına erişmek istediğini bildirir.

2-Google, bu talebi doğrudan kabul etmek yerine kullanıcıyı bir yetkilendirme ekranına yönlendirir.

Bu ekranda kullanıcıya:

• Hangi servisin erişim talep ettiği,

• Hangi tür izinlerin istendiği (örneğin yalnızca dosya okuma),

• Bu erişimin hangi amaçla kullanılacağı
  açık bir şekilde sunulur.

3-Kullanıcı, talebi onayladığı takdirde Google bu servise erişim belirteci (access token) üretir.

Bu access token, OAuth bağlamında sınırlı yetkilere sahip bir kimlik bilgisi olarak değerlendirilir. Tam kullanıcı kimlik bilgileri paylaşılmaz; bunun yerine yalnızca kullanıcının onayladığı kapsam (scope) dahilinde işlem yapabilen geçici bir yetki verilir. Bu yapı, valet anahtar analojisinde olduğu gibi, erişimi yalnızca gerekli işlevlerle sınırlar.

Bundan sonraki adımlarda fotoğraf baskı servisi, Google Drive API’sine yaptığı her istekte bu access token’ı kullanır. Google, gelen istekteki token’ı doğrular; token geçerli ve yetki kapsamı uygun ise ilgili kaynağa erişime izin verir. Aksi durumda erişim reddedilir.

Bu yaklaşım sayesinde:

• Kullanıcı parolaları üçüncü taraf servislerle paylaşılmaz,

• Erişim kapsamı net bir şekilde sınırlandırılır,

• Kullanıcı, verileri üzerindeki kontrolü tamamen elinde tutar.

OAuth 2.0 Terminolojisi

OAuth uygulamalarında, makalelerde ve dokümantasyonlarda karşılaşacağınız temel terminolojiyi analojimiz üzerinden anlatmaya devam edelim;

1. Resource (Kaynak)

Resource, OAuth akışındaki tüm aktörlerin erişmeye çalıştığı şeydir. Korunan kaynak (protected resource) olarak da adlandırılır.Örneğimizde kaynak nedir? Google Drive'daki fotoğraflar. OAuth akışının tüm amacı bu kaynağa erişim sağlamaktır.

2. Resource Owner (Kaynak Sahibi)

Resource Owner, kaynağa şu anda erişimi olan kişidir - yani kullanıcı. OAuth spesifikasyonundaki tanımı: "Korunan kaynağa erişim izni verebilen varlıktır." Fotoğraf baskı servisi örneğini düşünürsek, kaynağa erişime ihtiyaç duyuyor, bu örnekte erişimi -Kaynak sahibi, yani fotoğrafları Google Drive'da olan kişi- verebilir.

3. Resource Server (Kaynak Sunucusu)

Resource Server, korunan kaynağı barındıran sunucudur. Örneğimizde Google Drive kaynak sunucusudur.Kaynak sunucusu korunan kaynağı barındırıp ve yönetir.

4. Client (İstemci)

Client, korunan kaynağa erişmesi gereken uygulamadır. Kaynak sahibi adına ve kaynak sahibinin yetkilendirmesiyle korunan kaynağa istekte bulunan uygulamadır.

Örneğimizde:

• Kullanıcı (laptop başındaki kişi) = Resource Owner

• Google Drive = Resource Server

• Fotoğraf baskı servisi = Client

5. Authorization Server (Yetkilendirme Sunucusu)

Güvenlik sorumluluğu kaynak sunucunun üzerindedir. Kaynak sunucusu, kaynağın güvenliğini sağlamakla yükümlüdür.Bu nedenle kaynak sunucusu genellikle bir Authorization Server ile birlikte gelir. Yetkilendirme sunucusu, kaynağa erişen herkesin yetkili olduğundan emin olmaktan sorumludur. Authorization Server, client'a access token'lar veren sunucudur.

Bilgi: Resource Server ve Authorization Server aynı sunucu olabilir veya ayrı sunucular olabilir. Spesifikasyon bu konuda detaylı bilgi vermez, ancak kavramsal olarak iki ayrı sorumluluk alanı olarak düşünülebilir.

OAuth 2.0 Akışları (Flows)

OAuth için kurgulanmış olan akışlar ve uygulamalar mevcuttur. Bu bölümde bilmeniz gereken üç önemli akışı inceleyeceğiz.

1. Authorization Code Flow (Yetkilendirme Kodu Akışı)

En güvenli ve en çok önerilen OAuth akışıdır. Kaynak sahibi, client ve authorization server arasında gerçekleşir.

• Kullanıcı, client uygulamasında “Google hesabımla giriş yap” / “hesabıma erişim izni ver” gibi bir işlem başlatır.

• Client, kullanıcıyı Authorization Server’a yönlendirir (genellikle tarayıcı üzerinden redirect).

• Authorization Server, kullanıcıyı doğrular (login ekranı gösterir) ve hangi izinleri (scope) istediğini gösterir.

• Kullanıcı izinleri onaylar (Consent ekranı).

• Authorization Server, client’a authorization code (tek kullanımlık, kısa ömürlü kod) verir → bunu redirect_uri üzerinden client’a geri gönderir.

• Client, bu authorization code’u alır ve Authorization Server’a arka planda (backend-to-backend) bir istek yapar:

code + client_id + client_secret + redirect_uri

• Authorization Server kodu doğrular ve client’a şu ikiliyi verir:

access_token (kısa ömürlü, kaynak erişimi için kullanılır)

refresh_token (isteğe bağlı, uzun ömürlü; access token yenilemek için)

• Client artık access_token’ı kullanarak Resource Server’a (örneğin Google API, Drive, Gmail vs.) istek yapar.

• Resource Server token’ı doğrular ve istenen kaynağı (veri) döndürür.

Neden en güvenli kabul edilir?

Authorization code , tarayıcıda açıkta dolaşmaz. Access token ve özellikle client_secret sadece backend’de kullanılır. Refresh token ile uzun süreli erişim güvenli şekilde yönetilebilir.

2. Implicit Flow (Örtük Akış)

Implicit Flow, Authorization Code Flow'a benzer ancak biraz daha basitleştirilmiştir.

Akış şu şekilde çalışır:

Adım 1-4: İlk dört adım Authorization Code Flow ile aynıdır. Kullanıcı istek yapar, client authorization server'a gider, authorization server kullanıcıdan onay alır.

Adım 5: Authorization server, authorization token verip client'ın bunu access token'a dönüştürmesini beklemek yerine, doğrudan access token gönderir.

Adım 6-7: Client bu access token ile doğrudan resource server'ı çağırır ve kaynağı alır.

Bu akışın bir dezavantajı vardır: Access token, kaynağa erişmek için gereken tek şeydir. Birisi access token'a erişirse, bu servis gibi davranıp kaynağa erişebilir.

Authorization Code Flow'da access token daha güvenli bir şekilde değiştirilebilir, bu nedenle daha güvenlidir.

Implicit Flow şu durumlarda kullanılır

:• JavaScript uygulamaları (tarayıcıda çalışan)

• Access token'ın zaten çok güvenli olmadığı durumlar (tarayıcıda saklanacak)

• Basit ve hızlı entegrasyon gereken durumlar

Bu akışta access token'lar kısa ömürlü olmalıdır.

Implicit Flow artık önerilmemektedir, Modern uygulamalarda PKCE ile Authorization Code Flow kullanılması tavsiye edilir.

3. Client Credentials Flow (İstemci Kimlik Bilgileri Akışı)

Bu akış, microservices için uygun bir kullanım akışıdır. Client'ın güvenilir olduğu durumlarda genellikle kullanılır.

Örnek:İki microservice'imiz olsun. Microservice 1, Microservice 2'deki bir API'yi çağırmak istesin. Microservice 2'nin veritabanına erişimi var. Microservice 1, Microservice 2'yi çağırdığında sadece belirli API'lere erişebilmeli, diğer API'lere ve verilere erişememeli.

Client Credentials Flow şu şekilde çalışır:

Adım 1: Microservice 1, Microservice 2'deki bir API'yi çağırmak ister.

Adım 2: Önce OAuth sunucusuna bir çağrı yapar ve özel bir client ID sağlar: (kendisini tanıtır)

Adım 3: OAuth mikroservisi doğrular, belirli kaynaklara erişim için gerekli olan access token'ı hazırlayıp verir.

Adım 4: Microservice 1 bu token'ı saklar.

Adım 5: Microservice 1, Microservice 2'yi çağırır. Microservice 2 token'ı kontrol eder.

Adım 6: Eğer Microservice 1 , token'ın yetkisinin bulunmadığı bir kaynağa erişmeye çalışırsa, bu isteği reddedilir.

Client Credentials Flow, microservice mimarilerinde servisler arası yetkilendirme genellikle tercih edilir. Her microservice'in ihtiyaç duyduğu verilere erişmesini sağlar.

4. PKCE Flow (Proof Key for Code Exchange)

PKCE, Authorization Code Flow'un bir uzantısıdır. Özellikle mobil uygulamalar ve Single Page Applications (SPA) için tasarlanmıştır. Implicit Flow'un yerini almıştır.

PKCE'nin temel akışını aşağıdaki gibi özetleyebiliriz:

1. Client rastgele bir "code verifier" oluşturur

2. Bu verifier'ın hash'ini (code challenge) authorization server'a gönderir

3. Authorization code alındığında, orijinal verifier'ı da gönderir

4. Server, verifier'ın hash'inin önceki challenge ile eşleştiğini doğrular

Bu sayede authorization code ele geçirilse bile, code verifier olmadan access token alınamaz.

Access Token Formatı: JWT

Access token'larda , verilen izinler , eksiksiz bir şekilde barındırılmalıdır. Aynı zamanda doğrulanabilir olmalıdır. Günümüzde yaygın olarak kullanılan access token türü JWT(JSON Web Token) token'dir. JWT, OAuth 2.0'da access token formatı olarak yaygın şekilde kullanılmaktadır.

JWT üç parçadan oluşur:

1. Header: Token tipini ve imzalama algoritmasını barındırır.

2. Payload: Kullanıcı bilgileri ve izinler'i içerir.

3. Signature: Token'ın değiştirilmediğini doğrulayan bir imza içerir.

Örnek bir JWT token yapısı:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

OAuth 2.0'ın Avantajları

• Delegated Access (Yetkilendirilmiş Erişim): Kullanıcı kimlik bilgilerini paylaşmadan servisler arası erişim sağlayabilir.

• Açık Standart: İnternet üzerindeki tüm servisler birbirleriyle haberleşebilmek için aynı kurallar bütününü takip eder.

• Sınırlı Erişim: "Valet" anahtar gibi, sadece belirli işlemler için izin verilebilir.

• Güvenlik: Access token'lar kısa ömürlü olabilir ve gerektiğinde iptal edilebilir.

• Kullanıcı Kontrolü: Kullanıcı hangi izinleri vereceğine kendisi karar verebilir.

• Scope Bazlı İzinler: Farklı seviyede erişim izinleri tanımlanabilir.

Güvenlik Hususları

OAuth 2.0 kullanırken dikkat edilmesi gereken güvenlik noktaları:

1. State Parameter: CSRF saldırılarına karşı koruma sağlar. Her authorization isteğinde benzersiz bir state değeri gönderilmeli ve callback'te doğrulanmalıdır

2. HTTPS Zorunluluğu: OAuth akışı mutlaka HTTPS üzerinden gerçekleşmelidir. HTTP üzerinden token'lar ele geçirilebilir

3. Token Saklama: Access token'lar güvenli şekilde saklanmalıdır. Tarayıcıda localStorage yerine httpOnly cookie tercih edilmelidir.

4. Token Ömrü: Access token'lar kısa ömürlü olmalı (1 saat gibi), refresh token'larla yenilenmelidir.

5. Scope Minimizasyonu: Sadece gereken izinler istenmelidir.

Sonuç

OAuth 2.0, modern web uygulamalarında servisler arası güvenli yetkilendirme için vazgeçilmez bir standarttır. Valet anahtar analojisinde olduğu gibi, tam kimlik bilgileri paylaşmak yerine sınırlı erişim sağlayan token'lar kullanır.

• Resource: Erişilmek istenen kaynak

• Resource Owner: Kaynağın sahibi (kullanıcı)

• Resource Server: Kaynağı barındıran sunucu

• Client: Kaynağa erişmek isteyen uygulama

• Authorization Server: Token'ları veren sunucu

Dört önemli akışı inceledik:

1. Authorization Code Flow: En güvenli, önerilen akış

2. Implicit Flow: Eski yöntem, artık önerilmiyor

3. Client Credentials Flow: Microservices için ideal akış

4. PKCE Flow: Mobil ve SPA uygulamaları için güvenli akış

Zaman ayırıp bu yazıyı okuduğunuz için teşekkür ederim.
İçeriğin faydalı olmasını dilerim.Yeni yazılar için celsushub'ı ziyaret etmeyi unutmayın.