Serveur dautorisation et serveur de ressources

de ressources Le serveur de ressources est le terme OAuth 2.0 désignant votre serveur d’API. Le serveur de ressources traite les demandes authentifiées une fois que l’application a obtenu un jeton d’accès.

Les déploiements à grande échelle peuvent comporter plusieurs serveurs de ressources. Les services de Google, par exemple, disposent de dizaines de serveurs de ressources, tels que la plate-forme Google Cloud, Google Maps, Google Drive, Youtube, Google+ et bien d’autres. Chacun de ces serveurs de ressources est distinct, mais ils partagent tous le même serveur d’autorisation.

Les déploiements plus petits n’ont généralement qu’un seul serveur de ressources et sont souvent créés dans le cadre de la même base de code ou du même déploiement que le serveur d’autorisation.

Vérification des jetons d’accès

Le serveur de ressources reçoit des demandes d’applications avec un en-tête HTTP contenant un jeton d’accès. Le serveur de ressources doit être en mesure de vérifier le jeton d’accès pour déterminer s’il faut traiter la demande, trouver le compte d’utilisateur associé, etc.

Si vous utilisez des jetons d’accès auto-encodés, la vérification des jetons peut être effectuée entièrement dans le serveur de ressources sans interagir avec une base de données ou des serveurs externes.

Si vos jetons sont stockés dans une base de données, la vérification du jeton est simplement une recherche dans la base de données sur la table des jetons.

Une autre option consiste à utiliser la spécification Token Introspection pour créer une API afin de vérifier les jetons d’accès. Il s’agit d’un bon moyen de gérer la vérification des jetons d’accès sur un grand nombre de serveurs de ressources, car cela signifie que vous pouvez encapsuler toute la logique des jetons d’accès dans un seul serveur, en exposant les informations via une API à d’autres parties du système. Le point de terminaison d’introspection de jeton est destiné à être utilisé uniquement en interne, vous voudrez donc le protéger avec autorisation interne, ou ne l’activer que sur un serveur à l’intérieur du pare-feu du système.

Vérification de

l’étendue Le serveur de ressources a besoin de connaître la liste des étendues associées au jeton d’accès. Le serveur est responsable du refus de la demande si les étendues du jeton d’accès n’incluent pas l’étendue requise pour effectuer l’action désignée.

La spécification OAuth 2.0 ne définit pas elle-même de portées, et il n’existe pas non plus de registre central des portées. La liste des étendues est laissée à la discrétion du service. Pour plus d’informations, reportez-vous à la section Étendue.

Jetons expirés

Si votre service utilise des jetons d’accès de courte durée avec des jetons d’actualisation de longue durée, vous devez vous assurer de renvoyer la réponse d’erreur appropriée lorsqu’une application effectue une demande avec un jeton expiré.

Renvoie une réponse HTTP 401 avec un en-tête comme décrit ci-dessous. Si votre API renvoie des réponses JSON, puis vous pouvez également renvoyer un corps JSON avec les mêmes informations d’erreur.

HTTP/1.1 401 Unauthorized WWW-Authenticate : Bearer error="invalid_token » error_description="Le jeton d’accès a expiré » Content-type : application/json { « error » : « invalid_token », « error_description » : « Le jeton d’accès a expiré » }

Cela indiquera aux clients que leur jeton d’accès existant a expiré et qu’ils doivent essayer d’en obtenir un nouveau à l’aide de leur jeton d’actualisation.

Codes d’erreur et accès non autorisé

Si le jeton d’accès ne permet pas l’accès à la ressource demandée, ou s’il n’y a pas de jeton d’accès dans la demande, le serveur doit répondre par une réponse HTTP 401 et inclure un en-tête dans la réponse.

L’en-tête minimum inclut la chaîne , indiquant qu’un jeton de porteur est requis. L’en-tête peut également indiquer des des informations telles qu’un « domaine » et une « portée ». La valeur « realm » est utilisée dans le sens traditionnel de l’authentification HTTP. La valeur « scope » permet au serveur de ressources d’indiquer la liste des étendues requises pour accéder à la ressource, afin que l’application puisse demander l’étendue appropriée à l’utilisateur lors du démarrage du flux d’autorisation. La réponse doit également inclure une valeur « erreur » appropriée en fonction du type d’erreur qui s’est produite.

• (HTTP 400) : il manque un paramètre à la demande ou elle est incorrecte.
• (HTTP 401) : le jeton d’accès a expiré, est révoqué, incorrect ou non valide pour d’autres raisons. Le client peut obtenir un nouveau jeton d’accès et réessayer.
• (HTTP 403) – Le jeton d’accès

Par exemple :

HTTP/1.1 401 Non autorisé WWW-Authentifier : Porteur realm="example », scope="delete », error="insufficient_scope »

Si la requête n’a pas d’authentification, aucun code d’erreur ou autre information d’erreur n’est nécessaire.

HTTP/1.1 401 WWW-Authenticate non autorisé : Bearer realm="example »