Komunikacja OAuth v2 między uwierzytelnianiem a serwerem zasobów

Mam problemy ze zrozumieniem, jak działa OAUTH-v2.

Zgodnie ze specyfikacją protokołu OAuth w wersji 2 :

7. Dostęp do chronionych zasobów

   Klient uzyskuje dostęp do chronionych zasobów, przedstawiając
   token dostępu na serwerze zasobów. Serwer zasobów MUSI zweryfikować
   token dostępu i upewnić się, że nie wygasł i że jego zakres obejmuje
   żądany zasób. Metody używane przez serwer zasobów do
   sprawdzania poprawności tokenu dostępu (jak również odpowiedzi na błędy) wykraczają poza zakres tej specyfikacji , ale generalnie obejmują interakcję lub koordynację między serwerem zasobów a
   serwerem autoryzacji .

Jak ta interakcja między serwerem zasobów a serwerem autoryzacji wygląda w praktyce?

• W jaki sposób serwer zasobów ustala, że ​​otrzymany token dostępu jest ważny?
• W jaki sposób serwer zasobów wyodrębnia dozwolony zakres z tokenu, aby sprawdzić, czy należy przyznać dostęp do określonego zasobu? Czy zakres jest zakodowany w tokenie dostępu, czy też serwer zasobów musi najpierw skontaktować się z serwerem autoryzacji?
• W jaki sposób jest ustanawiane zaufanie między serwerem zasobów a serwerem autoryzacji?

Atrybuty tokenu dostępu i metody używane do uzyskiwania dostępu do chronionych zasobów wykraczają poza zakres tej specyfikacji i są zdefiniowane w specyfikacjach towarzyszących.

Czy ktoś może podać przykłady atrybutów tokenów?

Powodem, dla którego jest to poza zakresem specyfikacji, jest szeroki zakres sposobów wykonania tego połączenia między dwiema jednostkami. Głównym pytaniem jest to, jak skomplikowane jest Twoje wdrożenie.

Na przykład, czy masz jeden serwer zarządzający uwierzytelnianiem i dostępem oraz zestaw odrębnych usług, z których każda ma własne serwery obsługujące wywołania API? A może masz tylko jedno urządzenie z jednym serwerem WWW, który obsługuje zarówno uwierzytelnianie / autoryzację, jak i wywołania API?

W przypadku pojedynczego boxu niewiele potrzeba, ponieważ wydający tokeny jest tym samym podmiotem, który je weryfikuje. Możesz zaimplementować tokeny, aby używać klucza tabeli bazy danych i wyszukiwać rekord w bazie danych (lub pamięci podręcznej) przy każdym żądaniu lub możesz zakodować zakres, identyfikator użytkownika i inne informacje bezpośrednio do tokenu i zaszyfrować je za pomocą symetrycznego lub asymetrycznego algorytm.

W środowisku rozproszonym sytuacja staje się nieco bardziej złożona, ale niewiele. Nadal wydajesz tokeny na serwerze autoryzacji, ale serwer zasobów potrzebuje sposobu, aby je zweryfikować. Może to zrobić, udostępniając serwerowi zasobów wewnętrzny interfejs API, aby poprosić serwer autoryzacji o „rozwiązanie” tokena (co może być szybkie w środowisku lokalnym) lub oba mogą ustanowić parę kluczy publiczny / prywatny lub symetryczny sekret i użyj tego do zaszyfrowania wszystkiego, czego potrzebuje serwer zasobów w tokenie.

Samodzielne tokeny są dłuższe, ale oferują znacznie lepszą wydajność na żądanie. Jednak mają swoją cenę - nie można ich tak naprawdę cofnąć, dopóki są nadal ważne (nie wygasły). Z tego powodu niezależne tokeny powinny być bardzo krótkotrwałe (pozostawienie dostępu otwartego po unieważnieniu - np. Wiele witryn używa jednej godziny), z tokenem odświeżania, który jest ważny przez rok lub dłużej, aby uzyskać nowe tokeny.

Jednym z przykładów interfejsu API od zasobów do serwera autoryzacji jest ten w witrynie Google Developers .
Nie określa jednak formatu tokena dostępu, ale odpowiedź wydaje się dość uniwersalna.