Як перевірити маркер доступу OAuth 2.0 для сервера ресурсів?

Коли клієнт просить сервер ресурсів отримати захищений ресурс з маркером доступу OAuth 2.0, як цей сервер перевіряє маркер? Протокол оновлення маркера OAuth 2.0?

Оновлення листопада 2015 року: Відповідно до Ханса З. нижче - це тепер дійсно визначено як частину RFC 7662 .

Оригінальний відповідь: Специфікація OAuth 2.0 ( RFC 6749 ) не чітко визначає взаємодію між сервером ресурсів (RS) та сервером авторизації (AS) для перевірки токена доступу (AT). Це дійсно залежить від формату / стратегії маркера AS - деякі жетони є самостійними (наприклад, веб-маркери JSON ), а інші можуть бути схожими на файли cookie сесії, оскільки вони лише посилаються на інформацію, що міститься на стороні сервера в AS.

У робочій групі OAuth відбулась певна дискусія щодо створення стандартного способу зв'язку в РС з АС для перевірки AT. Моя компанія (Ping Identity) придумав один такий підхід до нашої комерційної OAuth AS (PingFederate): https://support.pingidentity.com/s/document-item?bundleId=pingfederate-93&topicId=lzn1564003025072.html#lzn1564003025072__section_N10578_N1002A_N10001 . Для цього використовується взаємодія на основі REST, що дуже доповнює OAuth 2.0.

Google шлях

Перевірка токена Google Oauth2

Запит:

https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg

Відповісти:

{
  "audience":"8819981768.apps.googleusercontent.com",
  "user_id":"123456789",
  "scope":"https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
  "expires_in":436
} 

Microsoft шлях

Microsoft - Oauth2 перевірити авторизацію

Github шлях

Github - Oauth2 перевірити авторизацію

Запит:

GET /applications/:client_id/tokens/:access_token

Відповісти:

{
  "id": 1,
  "url": "https://api.github.com/authorizations/1",
  "scopes": [
    "public_repo"
  ],
  "token": "abc123",
  "app": {
    "url": "http://my-github-app.com",
    "name": "my github app",
    "client_id": "abcde12345fghij67890"
  },
  "note": "optional note",
  "note_url": "http://optional/note/url",
  "updated_at": "2011-09-06T20:39:23Z",
  "created_at": "2011-09-06T17:26:27Z",
  "user": {
    "login": "octocat",
    "id": 1,
    "avatar_url": "https://github.com/images/error/octocat_happy.gif",
    "gravatar_id": "somehexcode",
    "url": "https://api.github.com/users/octocat"
  }
}

Амазонський шлях

Увійти за допомогою Amazon - Посібник для розробників (грудень 2015, стор. 21)

Запит:

https://api.amazon.com/auth/O2/tokeninfo?access_token=Atza|IQEBLjAsAhRmHjNgHpi0U-Dme37rR6CuUpSR...

Відповідь:

HTTP/l.l 200 OK
Date: Fri, 3l May 20l3 23:22:l0 GMT 
x-amzn-RequestId: eb5be423-ca48-lle2-84ad-5775f45l4b09 
Content-Type: application/json 
Content-Length: 247 

{ 
  "iss":"https://www.amazon.com", 
  "user_id": "amznl.account.K2LI23KL2LK2", 
  "aud": "amznl.oa2-client.ASFWDFBRN", 
  "app_id": "amznl.application.436457DFHDH", 
  "exp": 3597, 
  "iat": l3ll280970
}

Оновлення відповіді @Scott T.: інтерфейс між сервером ресурсів та сервером авторизації для перевірки токенів був стандартизований в IETF RFC 7662 в жовтні 2015 року, див: https://tools.ietf.org/html/rfc7662 . Виклик перевірки зразка виглядатиме так:

POST /introspect HTTP/1.1
Host: server.example.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer 23410913-abewfq.123483

token=2YotnFZFEjr1zCsicMWpAA

та вибіркова відповідь:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "active": true,
  "client_id": "l238j323ds-23ij4",
  "username": "jdoe",
  "scope": "read write dolphin",
  "sub": "Z5O3upPC88QrAjx00dis",
  "aud": "https://protected.example.net/resource",
  "iss": "https://server.example.com/",
  "exp": 1419356238,
  "iat": 1419350238,
  "extension_field": "twenty-seven"
}

Звичайно, прийняття постачальниками та продуктами повинно відбутися з часом.

Специфікація OAuth 2.0 не визначає частину. Але може бути кілька варіантів:

1. Коли сервер ресурсів отримує маркер у заголовку Authz, він викликає API перевірки / інтроспекції на сервері Authz, щоб перевірити маркер. Тут сервер Authz може перевірити його або з використанням магазину DB Store, або з підтвердження підпису та певних атрибутів. У рамках відповіді він декодує маркер і надсилає фактичні дані маркера разом із залишковим часом закінчення.

2. Authz Server може шифрувати / підписувати маркер за допомогою приватного ключа, а потім publickey / cert може бути наданий Resource Server. Коли сервер ресурсів отримує маркер, він або розшифровує / перевіряє підпис, щоб перевірити маркер. Виймає вміст і обробляє маркер. Тоді він може або надати доступ, або відхилити.

Специфікація OAuth v2 вказує на:

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

Мій сервер авторизації має кінцеву точку веб-сервісу (SOAP), яка дозволяє Серверу ресурсів знати, чи дійсний_позначення доступу.