Wie validiere ich ein OAuth 2.0-Zugriffstoken für einen Ressourcenserver?

Wie überprüft dieser Server das Token, wenn ein Client einen Ressourcenserver auffordert, eine geschützte Ressource mit einem OAuth 2.0-Zugriffstoken abzurufen? Das OAuth 2.0-Aktualisierungstokenprotokoll?

Update Nov. 2015: Gemäß Hans Z. unten - dies ist nun tatsächlich als Teil von RFC 7662 definiert .

Ursprüngliche Antwort: Die OAuth 2.0-Spezifikation ( RFC 6749 ) definiert die Interaktion zwischen einem Ressourcenserver (RS) und einem Autorisierungsserver (AS) für die Validierung des Zugriffstokens (AT) nicht klar. Dies hängt wirklich vom Token-Format / der Token-Strategie des AS ab. Einige Token sind in sich geschlossen (wie JSON-Web-Token ), während andere einem Sitzungscookie ähneln können, da sie nur auf Informationen verweisen, die serverseitig auf dem AS gespeichert sind .

In der OAuth-Arbeitsgruppe gab es einige Diskussionen über die Schaffung einer Standardmethode für die Kommunikation eines RS mit dem AS zur AT-Validierung. Mein Unternehmen (Ping Identity) hat einen solchen Ansatz für unseren kommerziellen OAuth AS (PingFederate) entwickelt: https://support.pingidentity.com/s/document-item?bundleId=pingfederate-93&topicId=lzn1564003025072.html#lzn156400302501_N . Hierfür wird eine REST-basierte Interaktion verwendet, die OAuth 2.0 sehr ergänzt.

Google Weg

Google Oauth2-Token-Validierung

Anfrage:

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

Reagieren:

{
  "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 Weg

Microsoft - Oauth2 prüft eine Autorisierung

Github Weg

Github - Oauth2 prüft eine Autorisierung

Anfrage:

GET /applications/:client_id/tokens/:access_token

Reagieren:

{
  "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 Weg

Mit Amazon anmelden - Entwicklerhandbuch (Dez. 2015, Seite 21)

Anfrage :

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

Antwort :

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
}

Ein Update zur Antwort von @Scott T.: Die Schnittstelle zwischen Resource Server und Authorization Server für die Token-Validierung wurde im Oktober 2015 in IETF RFC 7662 standardisiert, siehe: https://tools.ietf.org/html/rfc7662 . Ein Beispiel für einen Validierungsaufruf würde folgendermaßen aussehen:

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

und eine Beispielantwort:

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"
}

Natürlich muss die Übernahme durch Anbieter und Produkte im Laufe der Zeit erfolgen.

Die OAuth 2.0-Spezifikation definiert das Teil nicht. Es kann jedoch mehrere Optionen geben:

1. Wenn der Ressourcenserver das Token im Authz-Header erhält, ruft er die Validate / Introspect-API auf dem Authz-Server auf, um das Token zu validieren. Hier kann der Authz-Server die Validierung entweder anhand des DB Store oder anhand der Signatur und bestimmter Attribute überprüfen. Als Teil der Antwort dekodiert es das Token und sendet die tatsächlichen Daten des Tokens zusammen mit der verbleibenden Ablaufzeit.

2. Authz Server kann das Token mit einem privaten Schlüssel verschlüsseln / signieren, und dann kann publickey / cert an Resource Server übergeben werden. Wenn der Ressourcenserver das Token erhält, entschlüsselt / überprüft er die Signatur, um das Token zu überprüfen. Nimmt den Inhalt heraus und verarbeitet das Token. Es kann dann entweder Zugriff gewähren oder ablehnen.

OAuth v2-Spezifikationen geben Folgendes an:

Zugriffstokenattribute und die Methoden für den Zugriff auf geschützte Ressourcen gehen über den Rahmen dieser Spezifikation hinaus und werden durch Begleitspezifikationen definiert.

Mein Autorisierungsserver verfügt über einen SOAP-Endpunkt (Webservice), mit dem der Ressourcenserver feststellen kann, ob das access_token gültig ist.