Antimodèle: Émettre des jetons d'actualisation sans appeler le flux d'actualisation
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Vous consultez la documentation d'Apigee et d'Apigee hybrid. Consultez la documentation d'Apigee Edge.
Les jetons d'actualisation permettent d'obtenir de nouveaux jetons d'accès valides une fois que le jeton d'accès d'origine a expiré ou a été révoqué. Les jetons d'actualisation sont éventuellement fournis avec des jetons d'accès avec certains types d'autorisation.
Antimodèle
Les jetons d'actualisation peuvent être émis par Apigee ou via des ressources externes.
Toutefois, il s'agit d'un antimodèle si le jeton d'actualisation n'est jamais utilisé via l'opération RefreshAccessToken.
Impact
La persistance des jetons d'actualisation a un impact négatif inutile sur les performances et la fiabilité du système d'authentification.
Bonne pratique
Si le jeton d'actualisation n'est jamais nécessaire
Si les jetons d'actualisation ne sont pas nécessaires, les développeurs doivent utiliser les types d'autorisation "identifiants client" ou "implicite" lors de la génération de nouveaux jetons d'accès.
Ces types d'autorisation n'émettent pas de jetons d'actualisation, ce qui est souhaitable si la fonctionnalité de jeton d'actualisation n'est pas requise.
Si le proxy n'effectue que des opérations de lecture avec des jetons d'actualisation
Apigee propose
GetOAuthV2Info, qui peut être utilisé pour récupérer les attributs du jeton d'actualisation. Les développeurs ne doivent pas utiliser cette règle pour valider les jetons d'actualisation.
Il s'agit d'un antimodèle si le jeton d'actualisation n'est jamais utilisé pour échanger contre un nouveau jeton d'accès. Notez qu'Apigee peut fonctionner avec des
jetons d'accès et d'actualisation externes. Si le flux de jetons d'actualisation se produit en dehors d'Apigee, il est fortement recommandé d'utiliser l'opération RefreshAccessToken afin que les jetons d'actualisation importés qui ne sont plus valides soient correctement supprimés du système Apigee.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/05 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/05 (UTC)."],[],[],null,["# Antipattern: Issuing refresh tokens without invoking refresh flow\n\n*You're viewing **Apigee** and **Apigee hybrid** documentation.\nView [Apigee Edge](https://docs.apigee.com/api-platform/antipatterns/issuing-refresh-tokens) documentation.*\n\n\nRefresh tokens are used to obtain new access tokens after the original access\ntoken has expired or been revoked. Refresh tokens are optionally issued along\nwith access tokens with some of the grant types.\n\nAntipattern\n-----------\n\n\nRefresh tokens can be issued either by Apigee or via external resources.\nHowever, this is an antipattern if the refresh token is never used via the\nRefreshAccessToken operation.\n\nImpact\n------\n\n\nPersisting refresh tokens unnecessarily negatively impacts both performance\nand reliability of the authentication system.\n\nBest practice\n-------------\n\n### If the refresh token is never needed\n\n\nIf refresh tokens are not needed, developers should use the 'client\ncredentials' or 'implicit' grant types when generating new access tokens.\nThese grant types do not issue refresh tokens, which is desirable if the\nrefresh token functionality is not required.\n\n### If the proxy performs only read operation with refresh tokens\n\n\nApigee offers\n[GetOAuthV2Info](https://cloud.google.com/apigee/docs/api-platform/reference/policies/get-oauth-v2-info-policy#refresh-token) which can be used to retrieve refresh token\nattributes. Developers should not use this policy to validate refresh tokens.\nIt is an antipattern that the refresh token is never used to exchange for a\nnew access token. Note that Apigee can work with\n[external access and refresh tokens](/apigee/docs/api-platform/security/oauth/use-third-party-oauth-system). If the refresh token flow happens\noutside of Apigee, it's highly recommended to use the RefreshAccessToken\noperation such that any imported refresh tokens no longer valid are properly\nremoved from the Apigee system.\n\nFurther reading\n---------------\n\n[Refreshing an access token](/apigee/docs/api-platform/security/oauth/access-tokens#refreshinganaccesstoken)"]]
