Зв'язок OAuth v2 між аутентифікацією та сервером ресурсів

У мене виникають проблеми з розумінням того, як працює OAUTH-v2.

Специфікація OAuth версії 2 говорить:

7. Доступ до захищених ресурсів

   Клієнт отримує доступ до захищених ресурсів, представляючи
   маркер доступу на сервері ресурсів. Сервер ресурсів ПОВИНЕН перевірити
   маркер доступу та переконатися, що термін його дії не минув і що його область охоплює
   запитуваний ресурс. Методи, що використовуються сервером ресурсів для
   перевірки маркера доступу (а також будь-яких відповідей на помилки), виходять за рамки цієї специфікації , але, як правило, передбачають взаємодію або координацію між сервером ресурсів та
   сервером авторизації .

Як ця взаємодія між сервером ресурсів та сервером авторизації працює на практиці?

• Як сервер ресурсів визначає, що отриманий маркер доступу є дійсним?
• Як сервер ресурсів витягує дозволену область дії з маркера, щоб перевірити, чи повинен бути наданий доступ до певного ресурсу? Чи кодується область дії у маркері доступу, або сервер ресурсів спочатку повинен зв’язатись із сервером авторизації?
• Як встановлюється довіра між сервером ресурсів та сервером авторизації?

Атрибути маркера доступу та методи, що використовуються для доступу до захищених ресурсів, виходять за рамки цієї специфікації та визначаються супутніми специфікаціями.

Хтось може навести приклади для атрибутів лексеми?

Причиною того, що ця специфікація виходить за рамки, є широкий спектр способів досягнення цього зв’язку між двома об’єктами. Головне питання полягає в тому, наскільки складним є ваше розгортання.

Наприклад, чи є у вас один сервер, який керує аутентифікацією та доступом, а також набір дискретних служб, кожна з яких має власні сервери, що обслуговують виклики API? Або у вас є лише одне вікно з одним веб-сервером, який обробляє і автентифікацію / авторизацію, і виклики API?

У випадку одного ящика потрібно не так багато, оскільки сутність, що видає маркери, така ж, як та, що перевіряє їх. Ви можете реалізувати маркери, щоб використовувати ключ таблиці бази даних і шукати запис у базі даних (або кеш-пам’яті) при кожному запиті, або ви можете кодувати область дії, ідентифікатор користувача та іншу інформацію безпосередньо в маркер і зашифрувати його, використовуючи симетричну або асиметричну алгоритм.

Що стосується розподіленого середовища, справа стає дещо складнішою, але не набагато. Ви все ще видаєте маркери на сервері авторизації, але серверу ресурсів потрібен спосіб перевірки цих. Він може зробити це, зробивши внутрішній API доступним для сервера ресурсів, щоб попросити сервер авторизації «вирішити» маркер (який може бути швидким у локальному середовищі), або вони можуть встановити пару відкритого / приватного ключа або симетричний секрет і використовуйте це, щоб зашифрувати все, що потрібно серверу ресурсів, у маркер.

Автономні маркери довші, але забезпечують набагато кращу продуктивність на запит. Однак вони мають свою ціну - ви не можете відкликати їх, поки вони ще діють (термін дії не минув). З цієї причини автономні маркери повинні бути дуже недовгими (все, що вам прийнятно, залишити доступ відкритим після того, як його було скасовано - наприклад, багато сайтів використовують одну годину), із оновленим маркером, придатним протягом року або більше, щоб отримати нові маркери.

Одним із прикладів API сервера авторизації ресурсів є той, що розміщений на веб-сайті Google Developers .
Він не вказує формат маркера доступу, проте відповідь видається досить універсальною.