Technical Tutorials

Modern uygulama güvenliği ortamında, kullanıcıları kimlik doğrulamanın ve kaynaklara erişim yetkilendirmenin nasıl yapılacağını anlamak hayati önem taşır. Geliştiriciler için OAuth 2.0 ve OpenID Connect (OIDC) arasındaki ayrım sadece akademik değildir; güvenli ve ölçeklenebilir uygulamalar oluşturmak için kritiktir. Sıkça birbirinin yerine kullanılsa da, bu protokoller birbirine tamamlayıcı ancak farklı amaçlar için hizmet eder. Bu yazı, her ikisinin teknik nüanslarını, nasıl entegre olduklarını ve uygulama için en iyi uygulamaları incelemektedir.

Temel: OAuth 2.0 Yetkilendirme Çerçevesi

Yaygın bir yanlış anlaşılmayı netleştirmek önemlidir: OAuth 2.0 bir kimlik doğrulama protokolü değil, bir yetkilendirme çerçevesidir. Erişim devri ile ilgilenir. Bir kullanıcının üçüncü taraf bir uygulamaya, başka bir hizmetteki (örneğin bir fotoğraf uygulamasının Instagram fotoğraflarınıza erişmesine izin vermesi gibi) kaynaklarına erişim izni vermesini istediğinde, OAuth 2.0 erişim belirteçlerini (access tokens) vermek için kullanılan standarttır.

OAuth 2.0'daki temel varlık Erişim Belirteci (Access Token)'dir. Bu belirteç, istemci uygulamasına verilen izinleri temsil eder. Kritik bir nokta olarak, erişim belirteçleri kullanıcının kim olduğunu tanımlamak için asla kullanılmamalıdır. Bunlar, yalnızca API isteklerini yetkilendirmek için tasarlanmış saydam (opaque) dizelerdir.

Mobil bir uygulamanın bir kullanıcının Spotify kütüphanesine erişim istediği bir senaryoyu ele alalım. Spotify sunucusu bir erişim belirteci verir. Mobil uygulama, API çağrısı yaparken bu belirteci Authorization başlığında gönderir:

GET /v1/me/tracks HTTP/1.1
Host: api.spotify.com
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA

Bu, uygulamanın parçaları okuyabilmesini sağlar ancak geçerli bir belirtece sahip olmanın ötesinde kullanıcının kimliğini doğrudan kanıtlamaz.

OAuth 2.0'ı Genişletmek: OpenID Connect

Eğer OAuth 2.0 "Bunu yapabilir miyim?" sorusuna yanıt veriyorsa, OpenID Connect "Sen kimsin?" sorusuna yanıt verir. OIDC, OAuth 2.0 çerçevesinin üzerine inşa edilmiş basit bir kimlik katmanıdır. İstemcilerin, bir yetkilendirme sunucusu tarafından gerçekleştirilen kimlik doğrulamaya dayanarak son kullanıcının kimliğini doğrulamasına ve son kullanıcı hakkında temel profil bilgilerini, birbirleriyle uyumlu ve REST benzeri bir şekilde elde etmesine olanak tanır.

OIDC'nin getirdiği temel eklemelerden biri ID Token (Kimlik Belirteci)'dir. Bu, kimlik doğrulama olayı hakkında iddialar (claims) içeren bir JSON Web Token (JWT)'dir. Saydam erişim belirtecinden farklı olarak, ID Token yapılandırılmıştır ve imzalanmıştır; bu da istemcinin, bir arka uç sunucusuna sorgu yapmasına gerek kalmadan kullanıcının kimliğini çözebilmesini ve doğrulamasını sağlar.

Pratik Uygulama: Yetkilendirme Kodu Akışı

Web uygulamaları için, PKCE (Kod Değişimi için Kanıt Anahtarı) ile Yetkilendirme Kodu Akışı önerilen yaklaşımdır. Bu akış, güvenlik ve kullanılabilirliği dengeleyerek müdahale saldırılarını azaltır.

Adım Adım Akış

Başlatma: İstemci bir kod doğrulayıcı (code verifier) ve kod meydan okuması (code challenge) oluşturur ve kullanıcıyı Yetkilendirme Sunucusuna yönlendirir.
Kimlik Doğrulama: Kullanıcı giriş yapar.
Yetkilendirme: Sunucu, bir yetkilendirme koduyla birlikte istemciye geri yönlendirir.
Belirteç Değişimi: İstemci, kodu bir access_token, bir id_token ve potansiyel olarak bir refresh_token ile değiştirir.

Belirteç uç noktasından (token endpoint) gelen yanıtı işlerken, sunucu şuna benzer bir JSON yükü döndürmelidir:

{
  "access_token": "SlAV32hkKG",
  "token_type": "Bearer",
  "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
  "expires_in": 3600
}

id_token, yayıncının (issuer) genel anahtarıyla imzasını kontrol ederek ve iss (yayıncı), aud (kitle) ve exp (son kullanma tarihi) gibi iddiaları doğrulayarak doğrulanmalıdır.

Güvenli Uygulama İçin En İyi Uygulamalar

Bu protokolleri uygulamak, güvenlik standartlarına sıkı bir uyumu gerektirir. Belirteç müdahalesini önlemek için her zaman HTTPS kullanın. Belirteçleri asla HttpOnly ve Secure bayrakları olmadan yerel depolamada veya çerezlerde saklamayın; uygun olduğunda kısa ömürlü belirteçler için oturum depolamasını (session storage) kullanın. Ayrıca, yetkilendirme kodu müdahale saldırılarına karşı savunmak için tek sayfa uygulamaları (SPA'lar) için bile her zaman PKCE uygulayın.

Sonuç

OAuth 2.0 ve OpenID Connect'i ustalaşmak, kıdemli arka uç ve ön uç geliştiriciler için bir geçiş törenidir. OAuth 2.0'ın devri, OIDC'nin ise kimliği ele aldığını anlayarak, hem güvenli hem de kullanıcı dostu sistemler mimarisi oluşturabilirsiniz. Hatırlatma: Erişim için OAuth'u, kimlik için OIDC'yi kullanın ve belirteçleri her zaman titizlikle doğrulayın. Tehdit ortamı gelişmeye devam ettikçe, bu standartlarla güncel kalmak, uygulamalarınızın modern kimlik tabanlı saldırılara karşı dirençli kalmasını sağlar.