Bir Doğrulayıcı Taraf, Tutucunun Sunduğu Bir Kimlik Bilgisini Nasıl Doğruluyor

SDK size bir imzanın geçerli olduğunu söylüyor. Verenin güveninizi hak edip etmediğini söylemiyor ve verenin anahtarını sizin için getirmeyecek: onu siz sağlamak zorundasınız. O sınır bu sayfadaki en önemli şeydir.

Üç adım, ve yalnızca biri bizim

1. Hangi verenleri kabul ettiğinize karar verin. Bu sizin politika kararınız. Yazılımımızdaki hiçbir şey onu vermiyor, önermiyor ya da kaydetmiyor.
2. O verenin açık anahtarını edinin. Bir did:solidus vereni için tanımlayıcıyı zincire karşı çözümleyin ve anahtarı belgeden okuyun: kimlik doğrulaması gerektirmeyen tek bir istek, bir çözümlemenin gerçekte ne döndürdüğü sayfasında gösterilmiş.
3. Sunulan kimlik bilgisini o anahtara karşı doğrulayın. Bu adım SDK'nındır.

1. adımın teknik bir cevabı yok. Hiç duymadığınız bir verenden gelen geçerli bir imza, hiç duymadığınız bir verenden gelen geçerli bir imzadır.

Doğrulamanın gerçekte neyi dayattığı, tarif edilmedi, çalıştırıldı

2026-07-31'de yayımlanmış pakete karşı temiz bir dizinden çalıştırıldı:

1 bearer credential, plain verify       → valid=true
2 credential expiring 2020-01-01        → valid=false  "Verify Error: JWT is expired"
3 Wrong issuer public key      → valid=false  "Verify Error: Invalid JWT Signature"
4 bearer + verifier demands key binding → valid=false  "KB-JWT required but not present in compact form"

3. durum, gerisini anlamlı kılan kontroldür: yanlış anahtar için valid=true döndüren bir doğrulayıcı doğrulamıyordur. Bu döndürmüyor.

2. durum bizi düzeltti. İşlevi okurken hiçbir süre dolumu kontrolü görmedik ve tazeliğin dayatılmadığını yazmak üzereydik. Dayatılıyor: alttaki kitaplık, süresi dolmuş bir kimlik bilgisini kodumuz onu görmeden geri çeviriyor. Okumayı yayımlamak yerine test ettik ve okuma yanlıştı.

Endişelenmeniz gereken 1. durum

Düz bir doğrulama hamiline bir kimlik bilgisini kabul ediyor. Kendi modül belgemiz bunu açıkça söylüyor: "bearer presentations remain accepted."

Yani bariz yolla yazılmış bir doğrulayıcının varsayılan duruşu şu: bu baytları kim uzatırsa inanırım. Kimlik bilgisi bir tutucu anahtarı olmadan verildiyse, ki bu verme varsayılanıdır: düz bir doğrulamadaki hiçbir şey, onun verildiği kişiyi onu kopyalayan herhangi birinden ayırmıyor.

Bunun düzelmesi için, zıt taraflarda, farklı kişilerce iki isteğe bağlı seçimin yapılması gerekiyor. Verenin kimlik bilgisini bir tutucu anahtarına bağlaması gerekiyor. Doğrulayıcının kanıt istemesi gerekiyor. Birini kaçırın ve elinizde fazladan adımları olan bir hamiline jeton olur.

Bir doğrulayıcı hamiline olanı nasıl reddediyor

Beklenen bir hedef kitle, beklenen bir tek kullanımlık değer ya da ikisini birden sağlayın. Sonra doğrulayıcı:

• bir Anahtar Bağlama JWT'sinin var olmasını gerektiriyor,
• tutucunun anahtarını kimlik bilgisinin cnf iddiasından çekiyor ve yoksa başarısız oluyor,
• anahtar bağlama imzasını o anahtara karşı kontrol ediyor,
• hedef kitleyi ve tek kullanımlık değeri ayrı ayrı kontrol ediyor, böylece hangisinin yanlış olduğunu öğreniyorsunuz,
• ve anahtar bağlama kanıtının sunulan tam kimlik bilgisi gövdesini kapsadığını kontrol ediyor.

Yukarıdaki 4. durum o yolun çalışmasıdır: anahtar bağlama isteyen bir doğrulayıcıya sunulan hamiline bir kimlik bilgisi geri çevriliyor ve hata tam olarak sebebini söylüyor.

Her seferinde taze bir tek kullanımlık değer isteyin. Yakalanmış bir sunumu sonradan işe yaramaz kılan şey budur ve bu bizim değil doğrulayıcının işidir.

İki dürüst keskin kenar

• Gövde bağlama kontrolü, alan yokken atlanıyor. Kanıt-bu-kimlik-bilgisini-kapsıyor kontrolü yalnızca tutucunun kanıtı o alanı taşıyorsa çalışıyor. Şartnameye katı davranış isteyen bir doğrulayıcı, kontrol edildiğini varsaymak yerine onu gerektirmeli. Buna bir istismar demiyoruz: hedef kitle ve tek kullanımlık değer kontrolleri hâlâ geçerli, ama "varsa kontrol edilir" ile "gereklidir" aynı şey değil ve fark açıkta durmalı.
• Siz bağlamadıkça iptal kontrol edilmiyor. Doğrulayıcı bir durum listesine ancak ona bir getirici verirseniz danışıyor. Yoksa iptal edilmiş bir kimlik bilgisi tam olarak canlı biri gibi doğrulanıyor. Ve kimlik bilgisi durumundaki sınır üstüne ekleniyor: dışarıdan keşfedilebilir yayımlanmış bir liste tanımlayıcısı yok.

Ne geri geliyor

Bir mantıksal değer, tutucunun açıklamayı seçtiği iddialar ve veren ile tür dizgileri. Bakım alanları soyuluyor: çağıran, onları seçici olarak açıklanabilir yapan düzeneği değil iddiaları görüyor.

Bu sayfadan neyi kontrol edemezsiniz

Yukarıdaki dört durumu yerel olarak ürettiğimiz bir anahtarla çalıştırdık, gerçek bir verenden gelen bir kimlik bilgisine karşı değil, çünkü bize bağlı olmayan hiçbir doğrulayıcı taraf üretimde hiçbir zaman bir Solidus kimlik bilgisini kabul etmedi: sizi yönlendirecek bir üretim akışı yok. Kodun ne yaptığı kontrol edilebilir; birinin ona dayandığı kontrol edilebilir değil, çünkü henüz kimse dayanmıyor.

İçerik planımız bu sayfayı /accept-a-credential olarak adlandırıyor. O rota canlı değil: 404 döndürüyor, kasıtlı olarak sahte bir yol da öyle.