OAuth ve API Kimlik Doğrulama: Anahtarlarınızı Güvende Tutmak

Bir API'yi internete açtığınız anda, ona kimin erişebileceği sorusuyla yüzleşirsiniz. Herkese açık bir API çoğu zaman istenmez; verinize, işlemlerinize ve kaynaklarınıza yalnızca yetkili tarafların ulaşmasını istersiniz. İşte kimlik doğrulama (authentication) ve yetkilendirme (authorization) tam da bu noktada devreye girer. Bu ikisi sık karıştırılır: kimlik doğrulama "sen kimsin?" sorusunu, yetkilendirme ise "sen neye izinlisin?" sorusunu yanıtlar. İyi bir güvenlik tasarımı, bu iki soruyu birbirinden net biçimde ayırır.

En Basit Yöntem: API Anahtarları

API anahtarı (API key), bir istemciyi tanımlayan gizli bir dizedir. İstemci her istekte bu anahtarı gönderir, sunucu da anahtarı tanıyorsa isteği kabul eder. Basitliği nedeniyle çok yaygındır, ancak sınırları vardır. Anahtar bir kez ele geçirildiğinde, onu ele geçiren kişi tüm yetkilere sahip olur. Bu yüzden API anahtarlarını korumak hayati önem taşır.

• Anahtarları asla istemci tarafı koda (JavaScript, mobil uygulama içi) gömmeyin; oradan kolayca okunurlar.
• Anahtarları sürüm kontrolüne (Git) eklemeyin; ortam değişkenlerinde saklayın.
• Her istemciye ayrı anahtar verin ki birini iptal etmek diğerlerini etkilemesin.
• Anahtarları düzenli olarak yenileyin (rotation) ve sızma şüphesinde derhal iptal edin.

Bir API anahtarı, evinizin anahtarı gibidir. Onu paspasın altına saklarsanız, güvenliğiniz sadece kimsenin bakmamasına bağlı kalır.

Token Tabanlı Kimlik Doğrulama

API anahtarlarının statik yapısına karşın, token tabanlı yöntemler daha esnek ve güvenlidir. Kullanıcı önce kimlik bilgileriyle giriş yapar, sunucu da ona zamanla geçersizleşen bir token (belirteç) verir. Sonraki isteklerde bu token kullanılır. En yaygın biçim, Bearer token olarak Authorization başlığında taşınmasıdır:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6...

Bu tokenlar genellikle JWT (JSON Web Token) formatındadır. JWT, içinde kullanıcı kimliği ve yetkileri gibi bilgileri barındırır ve bir imzayla korunur; böylece sunucu, tokenın değiştirilmediğini imzayı doğrulayarak anlar. Tokenların kısa ömürlü olması, çalınsalar bile hasarı sınırlar.

OAuth 2.0: Şifreyi Paylaşmadan Yetki Vermek

OAuth 2.0, günümüzün en yaygın yetkilendirme çerçevesidir. Çözdüğü asıl problem şudur: bir uygulamanın, sizin adınıza başka bir servise erişmesine, şifrenizi ona vermeden nasıl izin verirsiniz? "Google ile giriş yap" ya da "hesabınızdaki fotoğraflara erişim izni ver" gibi akışların arkasında OAuth vardır.

OAuth'un dâhiyane fikri, şifre yerine sınırlı yetkili tokenlar dağıtmasıdır. Bir uygulamaya, "sadece takvimimi okuyabilir ama silemez" gibi kapsamlı (scoped) bir erişim verirsiniz. Uygulama sizin şifrenizi hiç görmez; yalnızca kendisine verilen dar yetkili tokenı kullanır. İstediğiniz an bu yetkiyi iptal edebilirsiniz.

OAuth'ta Roller

• Kaynak sahibi (resource owner): Verinin sahibi olan kullanıcı.
• İstemci (client): Kullanıcı adına erişim isteyen uygulama.
• Yetkilendirme sunucusu: Kullanıcıyı doğrulayıp token veren sistem.
• Kaynak sunucusu: Korunan veriyi barındıran ve tokenı doğrulayan API.

Tipik Akış

1. Uygulama, kullanıcıyı yetkilendirme sunucusuna yönlendirir.
2. Kullanıcı giriş yapar ve istenen izinleri onaylar.
3. Yetkilendirme sunucusu, uygulamaya geçici bir yetki kodu verir.
4. Uygulama bu kodu, kendi gizli anahtarıyla birlikte token ile takas eder.
5. Uygulama artık bu tokenla API'ye erişebilir.

OAuth'un güzelliği, "her şeye ya da hiçbir şeye" mantığını kırmasıdır. Bir uygulamaya tam ihtiyacı kadar yetki verir, fazlasını vermezsiniz.

Ortak Güvenlik İlkeleri

Hangi yöntemi seçerseniz seçin, bazı ilkeler her zaman geçerlidir:

• Her zaman HTTPS: Şifresiz bir bağlantı üzerinden gönderilen her anahtar veya token, yol boyunca dinlenebilir.
• En az yetki ilkesi: Her istemciye yalnızca ihtiyacı olan yetkiyi verin.
• Sızıntı planı: Bir anahtarın sızması durumunda onu anında iptal edebileceğiniz bir mekanizma kurun.
• Kayıt ve izleme: Kimin ne zaman eriştiğini kaydedin; anormal davranışları fark etmenin tek yolu budur.
• Kısa ömürlü tokenlar: Uzun ömürlü tokenlar, çalındıklarında uzun süre tehlike oluşturur.

Doğru Yöntemi Seçmek

Basit bir sunucular arası entegrasyonda, iyi korunan bir API anahtarı çoğu zaman yeterlidir. Kullanıcıların üçüncü parti uygulamalara erişim vermesi gereken durumlarda ise OAuth kaçınılmazdır. Mobil ve tek sayfa uygulamalarda kısa ömürlü tokenlar ve yenileme tokenları (refresh token) tercih edilir. Önemli olan, kolaylık ile güvenlik arasındaki dengeyi projenizin gerçek ihtiyacına göre kurmaktır.

Berasoft olarak geliştirdiğimiz projelerde, dışa açılan her API'nin kimlik doğrulama katmanını en baştan tasarlarız; çünkü güvenlik sonradan eklenen bir yama değil, mimarinin temel taşıdır. Kurumsal sisteminiz için güvenli bir erişim modeli kurgulamak isterseniz bizimle iletişime geçebilirsiniz.

Sonuç

API güvenliği, "kim" ve "neye izinli" sorularını doğru yanıtlamakla başlar. API anahtarları sadelik sunar ama korunmaları şarttır; token tabanlı yöntemler esneklik ve kısa ömürlülükle güvenliği artırır; OAuth ise şifreyi paylaşmadan sınırlı yetki vermenin standardıdır. Hangi yöntemi seçerseniz seçin, HTTPS, en az yetki ilkesi ve sızıntıya hazırlıklı olmak vazgeçilmezdir. Güvenliği baştan doğru kurmak, sonradan yaşanacak krizlerin en ucuz sigortasıdır.