JWT ve OAuth: Temel farklar, nasıl birlikte çalışırlar ve en iyi uygulamalar

Kimlik doğrulamaya yeniysen ve giriş, ödeme veya kullanıcı verisi yöneten bir uygulama geliştiriyorsan, muhtemelen JWT ve OAuth terimlerini duymuşsundur. Karmaşık ve sadece "arka uç odaklı" konular gibi görünebilirler, fakat bunlar sadece güvenlik mühendislerinin meselesi değil.

API'ler, üçüncü parti entegrasyonlar ve AI, MCP, ajan tabanlı sistemler gibi yeni teknolojilerde bu ikili ürününün kullanılabilirliği, güvenliği ve büyümesinde doğrudan rol oynar. Temelleri öğrenmek, şu avantajları sağlar:

• En başından itibaren güvenli özellikler tasarlayabilirsin
• Mühendislik ekibinle etkili bir şekilde iletişim kurabilirsin
• Kimlik doğrulama ve kullanıcı akışları hakkında daha iyi ürün kararları verebilirsin
• Kullanıcı güvenini zedeleyen pahalı güvenlik hatalarından kaçınabilirsin

Örneğin, en güncel MCP standardında, yetkilendirme sistemi kanıtlanmış standartlara dayalı olarak inşa edilmiştir:

• OAuth 2.1 IETF Taslağı (draft-ietf-oauth-v2-1-13)
• OAuth 2.0 Yetkilendirme Sunucusu Meta Verisi (RFC8414)
• OAuth 2.0 Dinamik İstemci Kaydı Protokolü (RFC7591)
• OAuth 2.0 Korumalı Kaynak Meta Verisi (RFC9728)

Neden önemli?#

Arka uç kodu yazmasan bile:

• Geliştiriciler API'leri nasıl güvenceye alacaklarını, oturumları yöneteceklerini ve üçüncü parti hizmetlerle nasıl entegrasyon kuracaklarını öğrenirler.
• Ürün yöneticileri, giriş akışları, entegrasyonlar ve uygunluk hakkında ekiplerle ve iş ortaklarıyla konuşacak doğru terminolojiye sahip olur.
• Kurucular ve erken aşama ekipler, entegrasyonlar sırasında kırılacak ya da ihlallere açık zayıf giriş sistemleri inşa etmekten kaçınır.

JWT vs OAuth: İki temel kavram#

JWT (JSON Web Token) ve OAuth (Açık Yetkilendirme) genellikle birlikte kullanılır, fakat farklı amaçlara hizmet ederler.

Şöyle düşünebilirsin:

• OAuth, birine anahtarları nasıl vereceğin, ancak yalnızca girmesine izin verilen odalar için.
• JWT ise taşıdığı kimlik kartı, kimin olduğunu ve neler yapabileceğini gösteren kanıt.

Bir sonraki bölümde, onları yan yana inceleyerek farklarını ve nasıl birbirlerini tamamladıklarını net göreceksin.

OAuth 2.0 nedir?#

OAuth 2.0, bir uygulamanın (istemci) kullanıcının kaynaklarına sınırlı izinlerle erişmesini sağlayan, kullanıcının kimlik bilgilerini (ör. şifre) paylaşmaya gerek kalmadan çalışan yaygın bir yetkilendirme çerçevesidir.

OAuth’ın temel rolleri#

• İstemci: Erişim talebinde bulunan uygulama.
• Kaynak sahibi: Genellikle izin veren kullanıcı.
• Yetkilendirme sunucusu: Yetkilendirmeden sonra erişim jetonu yayımlar.
• Kaynak sunucusu: Korumalı kaynakları barındırır ve jetonları doğrular

Yaygın OAuth izin türleri (Akışlar)#

• Authorization Code Grant: En güvenlisi ve önerileni, özellikle PKCE ile tarayıcı, SPA ve mobil uygulamalar için.
• Implicit Grant: Artık güvenlik nedeniyle OAuth 2.1’de önerilmiyor.
• Kaynak Sahibi Parola Kimlik Bilgileri (ROPC): Kullanıcı adı ve şifreyi doğrudan jeton ile değiştirir; daha az güvenlidir.
• Client Credentials Grant: Sunucu-sunucu ya da makineden makinaya iletişim için.
• Device Flow: Klavyesi olmayan cihazlar için (ör. akıllı TV’ler), kullanıcının ikinci bir cihazdan yetki vermesini sağlar.

JWT (JSON Web Token) nedir?#

Bir JWT, iki taraf arasında iddiaların güvenli şekilde iletilmesi için açık bir standarttır (RFC 7519) ve kompakt, URL güvenli bir yolla çalışır.

JWT’nin yapısı#

Bir JWT, nokta (.) ile ayrılmış üç adet base64url kodlu bölümden oluşur:

1. Başlık: Algoritmayı (ör. HS256, RS256) ve jeton türünü (JWT) belirtir.
2. Yük: İddiaları (claims) içerir, örneğin:
   • iss (yayımlayan)
   • sub (konu, ör. kullanıcı ID)
   • aud (hedef kitle)
   • exp (geçerlilik süresi)
   • İhtiyaca göre özel iddialar
3. İmza – Jetonun kurcalanıp kurcalanmadığını doğrular.

Örnek:

JWT’ye bir örnek#

Aşağıda, tipik bir JWT’nin kodlanmış hali ve içeriğinin neyi temsil ettiğini göstermek için çözülmüş yapısı var.

Kodlanmış JWT (Base64URL)

Bu, nokta ile ayrılmış üç bölümden oluşur: header.payload.signature

Çözülmüş Yapı

• Başlık

• Yük

Yük, iddiaları içerir

• İmza

İmza, jetonun kurcalanmadığından emin olmamızı sağlar.

Temel özellikler#

• Kendi içinde yeterli: Tüm gerekli bilgi jetonun içinde.
• Durumsuz: Sunucu tarafında oturum saklamaya gerek yok.
• İmzalı: (isteğe bağlı olarak şifrelenmiş) özgünlüğü garanti eder.

JWT vs OAuth: Temel farklar#

Kısacası:

• JWT kap: Kimlik bilgilerini taşıyan pasaport gibi.
• OAuth sistem: Göç kontrolü gibi, kimin pasaportu olacağını ve neye erişebileceğini belirleyen sistem.

Ne zaman yalnızca JWT kullanılmalı?#

JWT’yi tek başına kullan:

• Tek sistemli kimlik doğrulama gerekiyorsa ve uygulaman kendi jetonunu yayımlayıp doğruluyorsa.
• Durumsuz oturum yönetimi için, sunucuda oturum verisi tutmadan kimlik doğrulamak istiyorsan.
• Basit API kimlik doğrulaması için, yalnızca temel erişim haklarını doğrulamak gereken dahili API’lerde.
• Performans odaklı doğrulama için, kaynak sunucuları jetonları bir auth sunucusuna gerek olmadan yerel olarak doğrulayabilsin.

Örnek:

Sana ait tek sayfalık uygulama ve arka uç API. API, sub (kullanıcı ID), rol ve exp (jeton süresi) iddialarını içeren JWT'yi yayımlar.

Ne zaman sadece OAuth kullanılmalı?#

JWT olmadan OAuth kullan:

• Kendi içinde yeterli jetonlara ihtiyacın yoksa ve bakılması gereken opak jetonlar uygunsa.
• Kaynak sunucusunun erişim vermeden önce her zaman yetkilendirme sunucusunu kontrol etmesini istiyorsan.
• JWT’nin uygun olmadığı eski veya regülasyon gerektiren ortamlardaysan.
• Amaç üçüncü parti uygulamalara sınırlı erişim için yetkilendirme devri ise.

Örnek:

Bir API, opak erişim jetonları verir ve her isteği yetkilendirme sunucusunu sorgulayarak doğrular.

Ne zaman hem JWT hem OAuth birlikte kullanılmalı?#

Birlikte kullan:

• Birden fazla servis veya API'n varsa, güvenli akış için OAuth, tüm servislerde doğrulanabilir jetonlar için JWT kullanmak istiyorsan.
• Google ile giriş gibi üçüncü parti giriş seçeneği veriyorsan, OAuth izin sürecini yönetir ve JWT erişim veya ID jetonu taşır.
• Her servisin JWT'yi yerel olarak doğrulayabildiği mikroservis mimarisi kullanıyorsan.
• OAuth’un delege etme modeli ve JWT’nin durumsuz doğrulamasının ölçeklenebilirliğine ihtiyacın varsa.

Örnek:

Uygulama, kullanıcılara Google ile giriş yapma imkanı sunar. OAuth yetki sürecini yönetir, Google JWT erişim jetonu verir ve API’lerin bunu yerel olarak doğruladıktan sonra veri döndürür.

JWT ve OAuth nasıl birlikte çalışır?#

Modern kimlik doğrulama/yetkilendirme kurulumlarında:

1. OAuth erişim izni akışını yönetir.
2. Yetkilendirme Sunucusu genellikle JWT olan bir erişim jetonu verir.
3. JWT API istekleriyle birlikte gönderilir ve kimlik ile izinleri ispatlar.

OAuth’ta özel jetonlar#

• ID jetonu: OpenID Connect’te kullanıcının kimliğini kanıtlamak için kullanılır; daima JWT’dir.
• Erişim jetonu: JWT ya da opak jeton olabilir.

JWT ve OAuth kullanımı için en iyi uygulamalar#

• HTTPS kullanın – jetonları taşırken koruyun.
• JWT’ler için kısa geçerlilik süresi ayarlayın; uzun oturumlar için yenileme jetonu kullanın.
  • https://auth.wiki/offline-access.
• Herhangi bir iddiaya güvenmeden önce imzayı doğrulayın.
• Jetonun uygulamanıza ait olduğunu doğrulamak için aud iddiasını kontrol edin.
• XSS riski varsa jetonları localStorage’da saklamaktan kaçının; güvenli çerezleri tercih edin.

Son düşünceler#

• OAuth 2.0 jetonların nasıl alınacağını ve kullanılacağını tanımlar.
• JWT, jetonun nasıl görüneceğini ve bilgiyi nasıl taşıyacağını tanımlar.
• Bunlar tamamlayıcıdır, birbirinin yerine geçemezler.

Çoğu modern API, yetki akışı için OAuth ve jeton temsili için JWT kullanır. Her ikisini de anlamak güvenli ve ölçeklenebilir kimlik doğrulama sistemleri tasarlamana yardımcı olur.