Kimlik doğrulama ve kaynak sunucusu arasında OAuth v2 iletişimi

OAUTH-v2'nin nasıl çalıştığını anlamakta bazı sorunlar yaşıyorum.

OAuth sürüm 2 Spec okur:

7. Korunan Kaynaklara Erişim

   İstemci, erişim
   belirtecini kaynak sunucusuna sunarak korumalı kaynaklara erişir . Kaynak sunucusu
   erişim belirtecini doğrulamalı ve süresinin dolmadığından ve kapsamının
   istenen kaynağı kapsadığından emin olmalıdır .
   Erişim belirtecini (ve ayrıca herhangi bir hata yanıtını) doğrulamak için kaynak sunucusu tarafından kullanılan yöntemler bu belirtimin kapsamı dışındadır , ancak genellikle kaynak sunucusu ile yetkilendirme
   sunucusu arasındaki bir etkileşimi veya koordinasyonu içerir .

Kaynak sunucusu ile yetkilendirme sunucusu arasındaki bu etkileşim pratikte nasıl çalışır?

• Kaynak sunucusu aldığı erişim belirtecinin geçerli olup olmadığını nasıl belirler?
• Kaynak sunucusu, belirli bir kaynağa erişim verilmesi gerekip gerekmediğini görmek için belirteçten izin verilen kapsamı nasıl çıkarır? Kapsam, erişim belirtecinde kodlanmış mı yoksa kaynak sunucusunun önce yetkilendirme sunucusuyla iletişim kurması gerekiyor mu?
• Kaynak sunucusu ile yetkilendirme sunucusu arasında güven nasıl kurulur?

Erişim belirteci öznitelikleri ve korumalı kaynaklara erişmek için kullanılan yöntemler , bu belirtimin kapsamı dışındadır ve tamamlayıcı belirtimlerle tanımlanır.

Birisi belirteç özniteliklerine örnekler verebilir mi?

Bunun spesifikasyon için kapsam dışı olmasının nedeni, iki varlık arasında bu bağlantıyı gerçekleştirmenin çok çeşitli yollarıdır. Ana soru, dağıtımınızın ne kadar karmaşık olduğudur.

Örneğin, kimlik doğrulama ve erişimi yöneten bir sunucunuz ve her birinin API çağrılarına hizmet eden kendi sunucuları olan bir dizi ayrı hizmetiniz var mı? Veya, hem kimlik doğrulama / yetkilendirmeyi hem de API çağrılarını yöneten bir web sunucusuna sahip tek bir kutunuz mu var?

Tek bir kutu olması durumunda, token veren kuruluş, bunları doğrulayanla aynı olduğundan çok fazlasına gerek yoktur. Bir veritabanı tablosu anahtarı kullanmak ve her istekte veritabanında (veya bellek önbelleğinde) kaydı aramak için belirteçler uygulayabilir veya kapsamı, kullanıcı kimliğini ve diğer bilgileri doğrudan belirteç içine kodlayabilir ve simetrik veya asimetrik kullanarak şifreleyebilirsiniz. algoritması.

Dağıtılmış bir ortamla uğraşırken işler biraz daha karmaşık hale gelir, ancak fazla değil. Yine de yetkilendirme sunucusunda belirteçler veriyorsunuz, ancak kaynak sunucusunun bunları doğrulamak için bir yola ihtiyacı var. Yetkilendirme sunucusundan jetonu "çözümlemesini" (yerel bir ortamda hızlı olabilen) istemek için kaynak sunucusuna dahili bir API sunarak bunu yapabilir veya ikisi bir genel / özel anahtar çifti veya simetrik sır oluşturabilir ve bunu kaynak sunucunun ihtiyaç duyduğu her şeyi belirteçte şifrelemek için kullanın.

Bağımsız belirteçler daha uzundur ancak istek başına çok daha iyi performans sunar. Ancak, bir fiyatla gelirler - hala geçerliyken (süresi dolmamışken) onları gerçekten iptal edemezsiniz. Bu nedenle, kendi kendine yeten belirteçler çok kısa ömürlü olmalıdır (iptal edildikten sonra erişimi açık bırakmak sizin için kabul edilebilir olan her neyse - örneğin birçok site bir saat kullanır), bir yıl veya daha uzun süre yeni belirteçler almak için iyi bir yenileme belirteci ile.

Kaynak yetkilendirme sunucusu API'sine bir örnek, Google Developers Web Sitesindekidir .
Yine de erişim belirtecinin biçimini belirtmiyor, ancak yanıt evrensel olarak oldukça kullanışlı görünüyor.