4. Considérations de sécurité

Puisqu'il existe de nombreuses façons différentes et valides de mettre en œuvre un système OAuth 2.0, il existe par conséquent de nombreuses façons pour un serveur d'autorisation de déterminer si un jeton est actuellement "actif" (active) ou non. Cependant, étant donné que les serveurs de ressources utilisant l'introspection de jeton s'appuient sur le serveur d'autorisation pour déterminer l'état d'un jeton, le serveur d'autorisation DOIT effectuer toutes les vérifications applicables par rapport à l'état d'un jeton. Par exemple, ces tests incluent ce qui suit :

Si le jeton peut expirer, le serveur d'autorisation DOIT déterminer si le jeton a expiré ou non.
Si le jeton peut être émis avant de pouvoir être utilisé, le serveur d'autorisation DOIT déterminer si la période de validité d'un jeton a commencé ou non.
Si le jeton peut être révoqué après avoir été émis, le serveur d'autorisation DOIT déterminer si une telle révocation a eu lieu ou non.
Si le jeton a été signé, le serveur d'autorisation DOIT valider la signature.
Si le jeton ne peut être utilisé que sur certains serveurs de ressources, le serveur d'autorisation DOIT déterminer si le jeton peut être utilisé ou non sur le serveur de ressources effectuant l'appel d'introspection.

Si un serveur d'autorisation omet d'effectuer une vérification applicable, le serveur de ressources pourrait prendre une décision de sécurité erronée basée sur cette réponse. Notez que toutes ces vérifications ne seront pas applicables à tous les déploiements OAuth 2.0 et il appartient au serveur d'autorisation de déterminer lesquelles de ces vérifications (et toutes autres vérifications) s'appliquent.

S'il n'est pas protégé et non limité, le point de terminaison d'introspection pourrait présenter un moyen pour un attaquant d'interroger une série de valeurs de jetons possibles, à la recherche d'un jeton valide. Pour empêcher cela, le serveur d'autorisation DOIT exiger l'authentification des ressources protégées qui doivent accéder au point de terminaison d'introspection et DEVRAIT exiger que les ressources protégées soient spécifiquement autorisées à appeler le point de terminaison d'introspection. Les spécificités de ces identifiants d'authentification ne relèvent pas du domaine de cette spécification, mais ces identifiants pourraient couramment prendre la forme de tout mécanisme d'authentification client valide utilisé avec le point de terminaison de jeton, d'un jeton d'accès OAuth 2.0, ou d'un autre mécanisme d'autorisation ou d'authentification HTTP. Une seule pièce de logiciel agissant à la fois comme client et comme ressource protégée PEUT réutiliser les mêmes identifiants entre le point de terminaison de jeton et le point de terminaison d'introspection, bien que cela fusionne potentiellement les activités des parties client et ressource protégée du logiciel et que le serveur d'autorisation PUISSE exiger des identifiants séparés pour chaque mode.

Puisque le point de terminaison d'introspection prend des jetons OAuth 2.0 comme paramètres et répond avec des informations utilisées pour prendre des décisions d'autorisation, le serveur DOIT supporter la sécurité de la couche transport (TLS) 1.2 [RFC5246] et PEUT supporter des mécanismes de couche transport supplémentaires répondant à ses exigences de sécurité. Lors de l'utilisation de TLS, le client ou la ressource protégée DOIT effectuer une vérification du certificat serveur TLS/SSL, comme spécifié dans [RFC6125]. Les considérations de sécurité de mise en œuvre peuvent être trouvées dans les Recommandations pour l'utilisation sécurisée de TLS et DTLS [BCP195].

Pour empêcher les valeurs des jetons d'accès de fuir dans les journaux côté serveur via les paramètres de requête, un serveur d'autorisation offrant l'introspection de jeton PEUT interdire l'utilisation de HTTP GET sur le point de terminaison d'introspection et exiger à la place que la méthode HTTP POST soit utilisée sur le point de terminaison d'introspection.

Pour éviter de divulguer l'état interne du serveur d'autorisation, une réponse d'introspection pour un jeton inactif NE DEVRAIT PAS contenir de revendications supplémentaires au-delà de la revendication "active" requise (avec sa valeur définie sur "false").

Puisqu'une ressource protégée PEUT mettre en cache la réponse du point de terminaison d'introspection, les concepteurs d'un système OAuth 2.0 utilisant ce protocole DOIVENT considérer les compromis de performance et de sécurité inhérents à la mise en cache d'informations de sécurité comme celle-ci. Un cache moins agressif avec un délai d'expiration court fournira à la ressource protégée des informations plus à jour (car elle devra interroger plus souvent le point de terminaison d'introspection) au coût d'une augmentation du trafic réseau et de la charge sur le point de terminaison d'introspection. Un cache plus agressif avec une durée plus longue minimisera le trafic réseau et la charge sur le point de terminaison d'introspection, mais au risque d'avoir des informations périmées sur le jeton. Par exemple, le jeton peut être révoqué alors que la ressource protégée s'appuie sur la valeur de la réponse mise en cache pour prendre des décisions d'autorisation. Cela crée une fenêtre pendant laquelle un jeton révoqué pourrait être utilisé sur la ressource protégée. Par conséquent, une durée de validité de cache acceptable doit être soigneusement considérée compte tenu des préoccupations et des sensibilités de la ressource protégée accédée et de la probabilité qu'un jeton soit révoqué ou invalidé pendant la période intermédiaire. Les environnements hautement sensibles peuvent choisir de désactiver entièrement la mise en cache sur la ressource protégée pour éliminer complètement le risque d'informations mises en cache périmées, encore une fois au coût d'une augmentation du trafic réseau et de la charge serveur. Si la réponse contient le paramètre "exp" (expiration), la réponse NE DOIT PAS être mise en cache au-delà du temps indiqué dans celui-ci.

Un serveur d'autorisation offrant l'introspection de jeton doit être capable de comprendre les valeurs de jeton qui lui sont présentées lors de cet appel. Le moyen exact par lequel cela se produit est un détail de mise en œuvre et ne relève pas du domaine de cette spécification. Pour les jetons non structurés, cela pourrait prendre la forme d'une simple requête de base de données côté serveur contre un stockage de données contenant les informations de contexte pour le jeton. Pour les jetons structurés, cela pourrait prendre la forme du serveur analysant le jeton, validant sa signature ou d'autres mécanismes de protection, et renvoyant les informations contenues dans le jeton à la ressource protégée (permettant à la ressource protégée d'ignorer le contenu du jeton, tout comme le client). Notez que pour les jetons portant des informations chiffrées qui sont nécessaires pendant le processus d'introspection, le serveur d'autorisation doit être capable de déchiffrer et de valider le jeton pour accéder à ces informations. Notez également que dans les cas où le serveur d'autorisation ne stocke aucune information sur le jeton et n'a aucun moyen d'accéder aux informations sur le jeton en analysant le jeton lui-même, il ne peut probablement pas offrir un service d'introspection.