3. Implementation Note (Note d'implémentation)

3. Implementation Note (Note d'implémentation)

OAuth 2.0 permet une flexibilité de déploiement en ce qui concerne le style des jetons d'accès. Les jetons d'accès peuvent être autonomes afin qu'un resource server (serveur de ressources) n'ait besoin d'aucune interaction supplémentaire avec un serveur d'autorisation émettant ces jetons pour prendre une décision d'autorisation du client demandant l'accès à une ressource protégée. Une conception système peut cependant utiliser à la place des jetons d'accès qui sont des descripteurs faisant référence à des données d'autorisation stockées sur le serveur d'autorisation. Cela nécessite par conséquent qu'un serveur de ressources émette une demande au serveur d'autorisation respectif pour récupérer le contenu du jeton d'accès chaque fois qu'un client présente un jeton d'accès.

Bien que ce ne soient pas les seules options, elles illustrent les implications pour la révocation. Dans ce dernier cas, le serveur d'autorisation est capable de révoquer un jeton d'accès précédemment délivré à un client lorsque le serveur de ressources relaie un jeton d'accès reçu. Dans le premier cas, certaines interactions backend (actuellement non standardisées) entre le serveur d'autorisation et le serveur de ressources peuvent être utilisées lorsque la révocation immédiate du jeton d'accès est souhaitée. Une autre alternative de conception consiste à émettre des jetons d'accès à courte durée de vie, qui peuvent être rafraîchis à tout moment en utilisant les jetons de rafraîchissement correspondants. Cela permet au serveur d'autorisation d'imposer une limite au temps révoqué lorsque les jetons d'accès sont utilisés.

L'approche de révocation de jeton choisie dépendra de la conception globale du système et de l'analyse des risques du fournisseur de services d'application. Le coût de la révocation en termes d'état requis et de surcharge de communication est finalement le résultat des propriétés de sécurité souhaitées.