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


147

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?


Le serveur est censé pouvoir valider le token qu'il a précédemment émis lui-même ... Habituellement, il s'agira d'une recherche de base de données ou d'un crypto (tokens auto-signés).
Thilo

Je vois. Qu'en est-il de ce cas, le propriétaire de la ressource WS et le client WS sont tous deux sur des appareils différents?
Ack le

5
Vous parlez du service d'authentification et du service de ressources? (le client / consommateur sera toujours sur un appareil différent et ne peut pas valider lui-même les jetons) Si tel est le cas, vous pouvez utiliser des jetons d'actualisation qui sont «coûteux» à vérifier (seul le serveur d'authentification peut le faire) mais qui durent longtemps et jetons d'accès qui expirent fréquemment et peuvent être vérifiés hors ligne.
Thilo

Réponses:


97

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.


Scott T, existe-t-il un moyen de voir un exemple de code sur la façon d'utiliser la fonctionnalité dans Ping Federate?
JavaHead

2
@JavaHead, il y a plus de détails sur le protocole sur notre site Web pour développeurs ici: developer.pingidentity.com/en/resources/… , le PingFederate OAuth Playground est livré sous la forme d'un ensemble de JSP qui peuvent être référencés comme code source pour valider les jetons. Il (ainsi que d'autres bibliothèques et exemples open source) peut être téléchargé à partir d'ici: developer.pingidentity.com/en/code.html
Scott T.

Scott, je recherche un exemple qui démontrerait l'octroi d'informations d'identification du client avec l'API Rest protégée par un serveur de ressources local et PingFederate en tant que serveur d'authentification. Le serveur de ressources local appellera ensuite le point de terminaison de validation. Avez-vous rencontré quelque chose comme ça?
JavaHead

@JavaHead encore une fois, c'est quelque chose pour lequel vous devriez pouvoir référencer le PingFederate OAuth Playground. Il montre à la fois le type d'octroi des informations d'identification du client et la validation d'un jeton d'accès par un serveur de ressources.
Scott T.

Dans le cas d'un jeton d'accès JWT, je suppose que vous ne voudriez généralement pas atteindre le point de terminaison d'introspection AS pour chaque demande entrante à la RS. Dans quel cas, une vérification RS de la signature et de la portée du jeton est-elle suffisante? Ou peut-être que le RS pourrait mettre en cache les réponses d'introspection de l'AS pendant un certain temps?
Gary

119

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
}

2
@gustavodiazjaimes Cela n'explique pas du tout comment le côté serveur reconnaît l'ID utilisateur attribué à partir d'un jeton.
user2284570

22
Je ne comprends pas tous les votes. Cela ne semble pas répondre à la question.
Duncan Jones

Quelqu'un sait-il si Azure Active Directory a un point de terminaison similaire pour vérifier si un jeton émis est valide?
user180940

2
En d'autres termes, lancez le vôtre.
AndroidDev

51

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.


Si vous utilisez OoenId Connect, nous ne devrions pas préférer la manière openid d'utiliser le jeton d'identification pour valider le jeton d'accès: openid.net/specs
...

1
@Renan: pour être en ligne avec la façon dont les portées sont demandées dans une demande d'autorisation, qui est avec un scopeparamètre de requête dont la valeur contient une liste de portées séparées par des espaces
Hans Z.

4
Veuillez ne pas utiliser le mot «normalisé» lorsque quelque chose n'a pas été officiellement accepté par un organe directeur. L'IETF RFC 7662 de février 2018 indique clairement qu'il s'agit d'une «proposition».
AndroidDev

1
@adnankamili Il n'existe pas de "proposition". Au moment où un document devient une RFC, il s'agit déjà d'une «norme proposée» qui a un poids significatif derrière elle. OAuth 2.0 lui-même est toujours un "standard proposé", donc je ne suis pas certain de ce que vous essayez de faire valoir.
Pace

15

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.


8

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.