web-dev-qa-db-fra.com

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?

oauthoauth-2.0
124
Ack

Update Nov. 2015 - selon Hans Z. ci-dessous - il est désormais défini comme faisant partie de RFC 7662 .

La spécification OAuth 2.0 ne définit pas clairement l'interaction entre un serveur de ressources (RS) et un serveur d'autorisations (AS) pour la validation de jeton d'accès (AT). Cela dépend vraiment du format/de la stratégie de jeton de l'AS - certains jetons sont autonomes (comme jetons Web JSON ), tandis que d'autres peuvent être similaires à un cookie de session en ce sens qu'ils renvoient simplement des informations à l'AS dans Mémoire.

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

87
Scott T.

Façon Google

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
}

Façon Microsoft

Microsoft - Oauth2 vérifie une autorisation

Façon Github

Github - Oauth2 vérifie 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 Amazon

Connexion avec Amazon - Guide 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
}
114
gustavodiazjaimes

Mise à jour de la réponse de @Scott T.: l'interface entre Resource Server et Authorization Server pour la validation des jetons a été normalisée dans la RFC 7662 de l'IETF 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 sûr, l'adoption par les vendeurs et les produits devra se faire avec le temps.

45
Hans Z.

La spécification OAuth 2.0 ne définit pas la pièce. Mais il pourrait y avoir quelques 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. Dans ce cas, le serveur Authz peut valider l’utilisation de la base de données ou la vérification de la signature et de 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 délai d'expiration restant.

  2. Authz Server peut inscrire/signer le jeton à l'aide d'une clé privée, puis publickey/cert peut être attribué à Resource Server. 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 un accès ou refuser.

8
dvsakgec

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 la présente spécification et sont définis par des spécifications associées.

My Authorization Server possède un point de terminaison Webservice (SOAP) qui permet au serveur de ressources de savoir si le code d'accès est valide.

7
Carlos AG