Comment valider un jeton d'accès OAuth 2.0 pour un serveur de ressources?

Lorsqu'un client demande à un serveur de ressources d'obtenir une ressource protégée avec un jeton d'accès OAuth 2.0, comment ce serveur valide-t-il le jeton? Le protocole de jeton d'actualisation OAuth 2.0?

Mise à jour de novembre 2015: selon Hans Z. ci-dessous - cela est désormais défini dans le cadre de la RFC 7662 .

Réponse originale: La spécification OAuth 2.0 ( RFC 6749 ) ne définit pas clairement l'interaction entre un serveur de ressources (RS) et un serveur d'autorisation (AS) pour la validation du jeton d'accès (AT). Cela dépend vraiment du format / de la stratégie du jeton de l'AS - certains jetons sont autonomes (comme les jetons Web JSON ) tandis que d'autres peuvent être similaires à un cookie de session en ce qu'ils ne font référence qu'à des informations conservées côté serveur sur l'AS.

Il y a eu des discussions au sein du groupe de travail OAuth sur la création d'un moyen standard pour un RS de communiquer avec l'AS pour la validation AT. Mon entreprise (Ping Identity) a mis au point une telle approche pour notre OAuth AS commercial (PingFederate): https://support.pingidentity.com/s/document-item?bundleId=pingfederate-93&topicId=lzn1564003025072.html#lzn1564003025072__section#lzn1564003025072__section . Il utilise pour cela une interaction basée sur REST qui est très complémentaire à OAuth 2.0.

Google way

Validation du jeton Google Oauth2

Demande:

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

Répondre:

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

Manière Microsoft

Microsoft - Oauth2 vérifier une autorisation

Façon Github

Github - Oauth2 vérifier une autorisation

Demande:

GET /applications/:client_id/tokens/:access_token

Répondre:

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

Façon amazonienne

Connexion avec Amazon - Manuel du développeur (décembre 2015, page 21)

Demande :

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

Réponse:

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
}

Une mise à jour sur la réponse de @Scott T.: l'interface entre Resource Server et Authorization Server pour la validation des jetons a été normalisée dans IETF RFC 7662 en octobre 2015, voir: https://tools.ietf.org/html/rfc7662 . Un exemple d'appel de validation ressemblerait à ceci:

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

et un exemple de réponse:

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

Bien entendu, l'adoption par les fournisseurs et les produits devra se faire avec le temps.

La spécification OAuth 2.0 ne définit pas la pièce. Mais il pourrait y avoir deux options:

1. Lorsque le serveur de ressources obtient le jeton dans l'en-tête Authz, il appelle l'API validate / introspect sur le serveur Authz pour valider le jeton. Ici, le serveur Authz peut le valider en utilisant DB Store ou en vérifiant la signature et certains attributs. Dans le cadre de la réponse, il décode le jeton et envoie les données réelles du jeton avec le temps d'expiration restant.

2. Authz Server peut crypter / signer le jeton à l'aide de la clé privée, puis publickey / cert peut être donné au serveur de ressources. Lorsque le serveur de ressources obtient le jeton, il déchiffre / vérifie la signature pour vérifier le jeton. Prend le contenu et traite le jeton. Il peut alors fournir l'accès ou le rejeter.

Les spécifications OAuth v2 indiquent:

Les attributs de jeton d'accès et les méthodes utilisées pour accéder aux ressources protégées sortent du cadre de cette spécification et sont définis par des spécifications complémentaires.

Mon serveur d'autorisation possède un point de terminaison de service Web (SOAP) qui permet au serveur de ressources de savoir si le jeton d'accès est valide.