Noktaları Bağlamak: OIDC kaynağının ve JWT erişim tokenlerinizin derinlemesine bir incelemesi

Arka Plan#

Bir önceki oturumda OpenID Connect (OIDC) Protokolü, yenileme tokenleri, erişim tokenleri ve kimlik tokenleri gibi önemli bileşenlere giriş yaptık ve uygulamanızda sağlam bir kimlik doğrulama oluşturmak için bu bileşenler gerekli. Ancak, topluluğumuzda hala sorular var ve tekrar eden bir soru: "Erişim tokenim neden bir JWT değil?”

Konseptlere yeni olanlar veya bir tekrara ihtiyaç duyanlar için, bu blog yazısı OIDC kaynak göstergeleri ile erişim tokenlerinin elde edilmesindeki rolleri arasındaki ilişki üzerine ışık tutmayı amaçlamaktadır.

OIDC kaynağını anlama#

Eğer OAuth 2.0 protokolüne aşinaysanız, "kaynak" terimi bir zil çalmalı. OIDC, OAuth 2.0 üzerine kurulduğu için aynı konsepti miras alır.

"Kaynak" veya "korunan kaynak", istemci uygulamanın kimliği doğrulanmış kullanıcı adına erişmek istediği bir varlığın temsilidir. Bu, kullanıcının bilgileri, sunucu API'leri veya sunucunuz tarafından yetkilendirilmiş başka veriler olabilir.

Protokole göre, kaynak, yetkilendirme sunucusuna yapılan taleplerde bir parametredir. Bu, https://my-company.com/api gibi bir mutlak URI olarak gösterilen bir değerdir. Kaynak için bir tanımlayıcı olarak hizmet eder, potansiyel olarak bir ağa erişilebilir konumu veya hatta benzersiz ama kurgusal bir URI'ye karşılık gelebilir.

Logto'da, “Admin Konsolu → API kaynakları” sayfası üzerinden bir “API kaynağı” oluşturabilirsiniz. Daha fazla detay için bu belgeye göz atabilirsiniz.

JWT erişim tokeni#

JWT (JSON web token) formatında erişim tokeni, erişim tokeni talebi sırasında "kaynak" parametresi belirtildiğinde sadece verilir ve bir takım iddia setlerini taşır, örneğin tokenin bütünlüğünü ve kullanıcının izinlerini garanti altına almak için bunları çözebilir ve doğrulayabilirsiniz.

Bu "kaynak" daha sonra JWT'deki aud token iddiasından biri olur, tokenin hedef kitleyi gösterir. Bkz. RFC-7519.

İşte, ilişki netleşir:

• Bir JWT tokeni talep ederken kaynak göstergesini belirtin.
• Kaynak göstergesi, aud token iddiasıyla hizalıdır.
• API istekleri yaparken, JWT erişim tokeni, taşıyıcı token başlığı olarak eklenmelidir. API sunucunuz, API isteğini güvence altına almak için aud iddiasını ve diğer izinle ilgili iddiaları çözüp doğrulamalıdır.
• Her erişim tokeni tek bir kaynağa karşılık gelir. Farklı URI'lerle kaydedilmiş birden çok API kaynağınız varsa, her biri için farklı erişim tokenleri talep edin.

🤔 Peki ya istemci erişim tokenini talep ederken kaynağı belirtmezse ne olur?

Şeffaf erişim tokeni#

Logto’nun durumunda, eğer kaynak göstergesi erişim tokeni talep edilirken belirtilmezse, yetkilendirme sunucusu bunun OIDC /userinfo uç noktası için olduğunu varsayar ve böylece istemcinin daha sonra kullanıcı profilini, kullanıcı kimliği, isim, e-posta vb. OIDC userinfo uç noktasından talep etmesine izin veren bir şeffaf erişim tokeni verilir.

Herhangi bir Logto SDK'sında, getAccessToken()'ı çağırırsanız veya resource parametresini belirtmeden doğrudan OIDC token uç noktasını talep ederseniz bu türden bir token alabilirsiniz.

Bu şeffaf erişim tokeninin kendi API kaynak istekleriniz için uygun olmadığını unutmayın, çünkü OIDC sunucusuna talepte bulunmadan bunu doğrulamanın bir yolu yoktur.

Özetle#

OIDC kaynakları, bir istemci uygulamanın kullanıcı adına erişmek istediği belirli veri veya hizmetleri tanımlar, JWT erişim tokenleri bu erişimi sağlamak için güvenli bir araç olarak hizmet eder. JWT erişim tokenlerindeki "aud" iddiası, kaynak göstergesi ile hizalıdır ve istemci isteklerinde izinlerin sunucular tarafından doğrulanmasına yardımcı olur.

Logto'da, şeffaf erişim tokeni yalnızca OIDC userinfo uç noktasından kullanıcı profil bilgilerini almak içindir, istemciler belirli bir kaynağa adanmış birden çok erişim tokeni talep edebilirler.

Umarız bu blog yazısı herhangi bir şüphenizi giderir ve noktaları sizin için birleştirir. Düşüncelerinizi bilmekten mutluluk duyarız.