Les jetons d’actualisation Google expirent-ils?

J’ai utilisé le jeton d’actualisation à plusieurs resockets en une courte période à des fins de test, mais je me demande si le jeton d’actualisation Google expire? Ou je peux appeler le même jeton d’actualisation pour obtenir un autre jeton d’access à plusieurs resockets sur une longue période (une semaine ou même des mois)?

    Les jetons d’actualisation émis par le serveur Google Auth n’expirent jamais – c’est tout l’intérêt des jetons d’actualisation. Le jeton d’actualisation expirera (ou deviendra-t-il non autorisé) lorsque l’utilisateur révoque l’access à votre application.

    Reportez-vous à ce document. Il indique clairement la fonction des jetons de rafraîchissement.

    Au lieu d’émettre un jeton de longue durée (généralement valable pour un an ou une durée de vie illimitée), le serveur peut émettre un jeton d’access de courte durée et un jeton de rafraîchissement de longue durée. Donc, en bref, vous pouvez utiliser les jetons de rafraîchissement encore et encore jusqu’à ce que l’utilisateur qui a autorisé l’access révoque l’access à votre application.

    C’est un fil très déroutant. La première réponse semble être correcte, mais ne cite en fait rien qui fasse autorité de la part de Google.

    La réponse la plus définitive que j’ai trouvée est en fait dans le terrain de jeu du développeur où vous obtenez le jeton. L’étape 2 a une note au bas qui dit:

    “Remarque: OAuth Playground ne stocke pas les jetons de rafraîchissement, mais lorsque les jetons de rafraîchissement n’expirent jamais, l’utilisateur doit accéder à la page Accès autorisé à son compte Google s’il souhaite les révoquer manuellement.”

    https://developers.google.com/oauthplayground/

    Je ne pense pas que cela soit complètement vrai:

    Notez qu’il existe des limites sur le nombre de jetons d’actualisation à émettre. une limite par combinaison client / utilisateur et une autre par utilisateur pour tous les clients. Vous devez enregistrer les jetons de rafraîchissement dans le stockage à long terme et continuer à les utiliser tant qu’ils restnt valides. Si votre application demande un trop grand nombre de jetons d’actualisation, elle risque de rencontrer ces limites, auquel cas les anciens jetons d’actualisation cesseront de fonctionner.

    à partir de cette page: https://developers.google.com/youtube/v3/guides/authentication#installed-apps

    C’est à partir de la documentation de YouTube (que je trouve bien meilleure que les autres documents d’API), mais je pense que c’est la même chose dans toutes les applications Google.

    regarde ça:

    Les jetons d’actualisation sont valides jusqu’à ce que l’utilisateur révoque l’access. Ce champ est uniquement présent si access_type = offline est inclus dans la demande de code d’autorisation.

    dans https://developers.google.com/accounts/docs/OAuth2WebServer

    Les règles ont changé en 2017, alors la meilleure réponse, à mon avis, est que cela dépend du produit. Par exemple, sur l’API Gmail, le jeton d’actualisation Oauth 2.0 expire lors de la modification du mot de passe. Consultez cette https://support.google.com/a/answer/6328616?hl=fr

    Nous avions l’habitude de configurer l’access à l’API à l’avance et de générer des jetons de rafraîchissement lorsque nous configurions de NOUVEAUX utilisateurs de gmail, puis nous pouvions archiver leur courrier (nous sums obligés de le faire par la loi) est révoqué.

    Peut-être que pour youtube, des cartes, le jeton de rafraîchissement est toujours vraiment long, mais pour l’API de gmail, comptez sur un jeton court.

    Le concept principal de jeton d’actualisation est qu’il est durable et n’expire jamais.

    Le jeton d’access a une date d’expiration et expire. Une fois qu’il arrive à expiration, nous pouvons choisir le jeton d’actualisation, qui sera utilisé encore et encore jusqu’à ce que l’utilisateur révoque son compte.

    J’ai fait des recherches supplémentaires et il semble que le jeton d’access Google soit utilisé pour récupérer un jeton d’actualisation lors de la première demande «hors ligne». À partir de ce point, le jeton d’actualisation est utilisé pour émettre un nouveau jeton d’access. L’idée est qu’un jeton d’access est un jeton à court terme, mais qu’il peut être renouvelé par un jeton de rafraîchissement à long terme. Cela supprime la nécessité de demander la variable URL ‘code’, qui nécessite une approche à deux points de terminaison et doit être initiée à l’aide d’une demande basée sur un référent:

    http://www.jensbits.com/2012/01/09/google-api-offline-access-using-oauth-2-0-refresh-token/

    Certains, des services API REST tels que Dropbox, émettent des jetons d’access qui durent éternellement, mais Google émet des jetons d’access à court terme. PayPal utilise un compromis qui permet de récupérer les jetons d’access sans application du référent URI. Cela signifie que les jetons d’access peuvent être récupérés sans avoir à cliquer sur un lien pour lancer le processus. La méthodologie de Google signifie que les routines API ne doivent être utilisées que sur une base de besoin d’utilisation. Essentiellement, les appels sont lancés via des procédures basées sur des référents. Ceci est contrôlé en émettant des jetons d’access de courte durée ou des jetons d’access qui doivent être actualisés dans une chaîne. Cela oblige les développeurs à réfléchir plus attentivement à la manière dont un système doit circuler.