Потік OAuth2 - чи підтверджує сервер сервер Auth?

10

Я багато читав на OAuth2, намагаючись обійти його головою, але все ще щось збентежив.

Я розумію, що клієнт авторизується з постачальником OAuth (наприклад, Google) і дозволяє Серверу ресурсів мати доступ до даних профілю користувача. Тоді клієнт може відправити маркер доступу на сервер ресурсів і повернути йому ресурс.

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

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

Хтось може вказати мені на просте дотримування пояснення OAuth2, оскільки поки що ті, які я прочитав, відчувають себе неповними.

security oauth2

— древка
джерело

8

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

— древка
джерело

1

Щодо важливих частин , можливо, варто прочитати цю публікацію в блозі, щоб ознайомитися з пріоритетами для OAuth2.

— Ларс Віклунд

1

Дякую за це, цікаве прочитання. Мої вимоги досить прості в тому, що я хочу дозволити додатку iOS аутентифікуватись з google, twitter, facebook тощо, передати певну форму авторизації на мій сервер, а сервер підтвердити його та забезпечити доступ до ресурсів. Проблема виявилася складнішою, ніж я передбачав, через складність розуміння того, як це працює, і що мені робити де.

— drekka

Точніше, додаток A: "Для перевірки підпису на запиті захищений ресурс міг би подати ідентифікатор маркера до кінцевої точки самоаналізу сервера авторизації для отримання необхідної ключової інформації, необхідної для цього маркера. Деталі цього використання знаходяться поза область цієї специфікації та буде визначена в розширенні [...] ".

— JulienD

2

Перевірка токенів, як правило, обробляється 1 із 2 способів.

1) Маркер криптографічно підписується за допомогою попередньо спільних ключів. Це очевидно короткий час для використання в розподілених, розповсюджуючих системах.

2) Сервер авторизації (AS) надає кінцеву точку для перевірки лексеми або інтроспекції. Цей метод був стандартизований в IETF RFC 7662 в жовтні 2015 року, див: https://tools.ietf.org/html/rfc7662

Цей запит / відповідь щодо переповнення стека містить приклади від Google та Github: /programming/12296017/how-to-validate-an-oauth-2-0-access-token-for-a-resource-server

— Хауї Росс
джерело

0

ви читаєте специфікацію, як перевірити маркер:

https://tools.ietf.org/html/rfc7662

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

— Чираг
джерело

4

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

— Томас Оуенс