Je commence tout juste à travailler avec Google API et OAuth2. Lorsque le client autorise mon application, je reçois un "jeton d'actualisation" et un "jeton d'accès" de courte durée. Maintenant, chaque fois que le jeton d'accès expire, je peux POSTER mon jeton d'actualisation sur Google et ils me donneront un nouveau jeton d'accès.

Ma question est quel est le but du jeton d'accès expirant? Pourquoi ne peut-il pas y avoir simplement un jeton d'accès durable au lieu du jeton d'actualisation?

De plus, le jeton d'actualisation expire-t-il?

Voir Utilisation d'OAuth 2.0 pour accéder aux API Google pour plus d'informations sur le flux de travail Google OAuth2.

Ceci est très spécifique à l'implémentation, mais l'idée générale est de permettre aux fournisseurs d'émettre des jetons d'accès à court terme avec des jetons d'actualisation à long terme. Pourquoi?

• De nombreux fournisseurs prennent en charge les jetons de support qui sont très faibles en termes de sécurité. En les rendant éphémères et nécessitant un rafraîchissement, ils limitent le temps qu'un attaquant peut abuser d'un jeton volé.
• Les déploiements à grande échelle ne souhaitent pas effectuer de recherche de base de données à chaque appel d'API, ils émettent donc à la place un jeton d'accès auto-codé qui peut être vérifié par déchiffrement. Cependant, cela signifie également qu'il n'y a aucun moyen de révoquer ces jetons, ils sont donc émis pour une courte période et doivent être actualisés.
• Le jeton d'actualisation nécessite une authentification client qui le rend plus fort. Contrairement aux jetons d'accès ci-dessus, il est généralement implémenté avec une recherche de base de données.

Quelques scénarios peuvent aider à illustrer le but des jetons d'accès et d'actualisation et les compromis d'ingénierie dans la conception d'un système oauth2 (ou tout autre auth):

Scénario d'application Web

Dans le scénario de l'application Web, vous avez deux options:

1. si vous avez votre propre gestion de session, stockez les access_token et refresh_token par rapport à votre identifiant de session dans l'état de session sur votre service d'état de session. Lorsqu'une page est demandée par l'utilisateur qui vous oblige à accéder à la ressource, utilisez access_token et si access_token a expiré, utilisez refresh_token pour obtenir la nouvelle.

Imaginons que quelqu'un réussisse à détourner votre session. La seule chose possible est de demander vos pages.

2. si vous n'avez pas de gestion de session, placez access_token dans un cookie et utilisez-le comme session. Ensuite, chaque fois que l'utilisateur demande des pages à votre serveur Web, envoyez le access_token. Votre serveur d'applications pourrait actualiser le access_token si nécessaire.

Comparer 1 et 2:

Dans 1, access_token et refresh_token voyagent uniquement sur le fil entre le serveur d'autorisations (google dans votre cas) et votre serveur d'applications. Cela se ferait sur un canal sécurisé. Un pirate pourrait détourner la session, mais il ne pourrait interagir qu'avec votre application Web. Dans 2, le pirate pourrait retirer le access_token et former ses propres demandes aux ressources auxquelles l'utilisateur a accordé l'accès. Même si le pirate prend possession du access_token, il n'aura qu'une courte fenêtre dans laquelle il pourra accéder aux ressources.

Dans tous les cas, le refresh_token et le clientid / secret ne sont connus que du serveur, ce qui empêche le navigateur Web d'obtenir un accès à long terme.

Imaginons que vous implémentiez oauth2 et définissiez un long délai d'attente sur le jeton d'accès:

Dans 1) Il n'y a pas beaucoup de différence ici entre un jeton d'accès court et long car il est caché dans le serveur d'application. Dans 2), quelqu'un pourrait obtenir le access_token dans le navigateur, puis l'utiliser pour accéder directement aux ressources de l'utilisateur pendant une longue période.

Scénario mobile

Sur le mobile, je connais quelques scénarios:

1. Stockez l'ID client / secret sur l'appareil et demandez à l'appareil d'orchestrer l'accès aux ressources de l'utilisateur.

2. Utilisez un serveur d'application principal pour conserver l'ID client / secret et lui faire l'orchestration. Utilisez access_token comme une sorte de clé de session et passez-la entre le client et le serveur d'applications.

Comparer 1 et 2

En 1) Une fois que vous avez clientid / secret sur l'appareil, ils ne sont plus secrets. N'importe qui peut décompiler puis commencer à agir comme s'il était vous, avec la permission de l'utilisateur bien sûr. Access_token et refresh_token sont également en mémoire et peuvent être accessibles sur un appareil compromis, ce qui signifie que quelqu'un pourrait agir comme votre application sans que l'utilisateur donne ses informations d'identification. Dans ce scénario, la longueur de access_token ne fait aucune différence pour le piratage, puisque refresh_token est au même endroit que access_token. Dans 2), l'ID client / secret ni le jeton d'actualisation sont compromis. Ici, la durée de l'expiration access_token détermine la durée pendant laquelle un pirate pourrait accéder aux ressources des utilisateurs, s'ils s'en emparaient.

Longueurs d'expiration

Ici, cela dépend de ce que vous sécurisez avec votre système d'authentification quant à la durée de votre expiration access_token. Si c'est quelque chose de particulièrement précieux pour l'utilisateur, il doit être court. Quelque chose de moins précieux, il peut être plus long.

Certaines personnes comme Google n'expirent pas le refresh_token. Certains comme stackflow le font. La décision d'expiration est un compromis entre facilité d'utilisation et sécurité. La longueur du jeton d'actualisation est liée à la longueur de retour de l'utilisateur, c'est-à-dire définir l'actualisation à la fréquence à laquelle l'utilisateur retourne dans votre application. Si le jeton d'actualisation n'expire pas, la seule façon dont ils sont révoqués est avec une révocation explicite. Normalement, une connexion ne serait pas révoquée.

J'espère que ce message plutôt long sera utile.

En plus des autres réponses:

Une fois obtenus, les jetons d'accès sont généralement envoyés avec chaque demande des clients aux serveurs de ressources protégés. Cela induit un risque de vol et de relecture de jetons d'accès (en supposant bien sûr que les jetons d'accès sont de type "Porteur" (tel que défini dans la RFC6750 initiale).

Exemples de ces risques, dans la vie réelle:

• Les serveurs de ressources sont généralement des serveurs d'applications distribués et ont généralement des niveaux de sécurité inférieurs à ceux des serveurs d'autorisation (configuration SSL / TLS inférieure, moins de renforcement, etc.). Les serveurs d'autorisation, en revanche, sont généralement considérés comme une infrastructure de sécurité critique et sont soumis à un renforcement plus sévère.

• Les jetons d'accès peuvent apparaître dans les traces HTTP, les journaux, etc. qui sont collectés légitimement à des fins de diagnostic sur les serveurs de ressources ou les clients. Ces traces peuvent être échangées sur des lieux publics ou semi-publics (bug tracers, service-desk, etc.).

• Les applications Backend RS peuvent être sous-traitées à des tiers plus ou moins fiables.

Le jeton d'actualisation, d'autre part, n'est généralement transmis que deux fois sur les câbles, et toujours entre le client et le serveur d'autorisation: une fois lorsqu'il est obtenu par le client, et une fois lorsqu'il est utilisé par le client pendant l'actualisation ("expirant" effectivement l'actualisation précédente jeton). Il s'agit d'une opportunité d'interception et de relecture drastiquement limitée.

Dernière réflexion, les jetons d'actualisation offrent très peu de protection, le cas échéant, contre les clients compromis.

Il s'agit essentiellement d'une mesure de sécurité. Si votre application est compromise, l'attaquant n'aura accès qu'au jeton d'accès de courte durée et aucun moyen d'en générer un nouveau.

Les jetons d'actualisation expirent également, mais ils sont censés vivre beaucoup plus longtemps que le jeton d'accès.