Pourquoi les jetons d’access expirent-ils?

Je commence à travailler avec Google API et OAuth2. Lorsque le client autorise mon application, on me donne un “jeton d’actualisation” et un “jeton d’access” de courte durée. Maintenant, chaque fois que le jeton d’access expire, je peux POSTER mon jeton d’actualisation sur Google et ils me donneront un nouveau jeton d’access.

Ma question est la suivante: quel est le but du jeton d’access expirant? Pourquoi n’y a-t-il pas juste un jeton d’access durable au lieu du jeton de rafraîchissement?

En outre, 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 stream 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’access à court terme avec des jetons d’actualisation à long terme. Pourquoi?

  • De nombreux fournisseurs prennent en charge les jetons porteurs qui sont très peu sécurisés. En les rendant de courte durée et nécessitant un rafraîchissement, ils limitent le temps pendant lequel un attaquant peut abuser d’un jeton volé.
  • Le déploiement à grande échelle ne veut pas effectuer une recherche dans la firebase database à chaque appel d’API. Par conséquent, ils émettent un jeton d’access auto-encodé qui peut être vérifié par décryptage. Cependant, cela signifie également qu’il n’y a aucun moyen de révoquer ces jetons pour qu’ils soient émis pendant une courte période et doivent être actualisés.
  • Le jeton d’actualisation requirejs une authentification client qui le rend plus puissant. Contrairement aux jetons d’access ci-dessus, il est généralement implémenté avec une recherche de firebase database.

Quelques scénarios peuvent aider à illustrer le but des jetons d’access et de rafraîchissement et les compromis d’ingénierie lors de la conception d’un système oauth2 (ou tout autre système d’authentification):

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 à la fois les identifiants access_token et refresh_token sur votre identifiant de session dans l’état de session de votre service d’état de session. Lorsqu’une page est demandée par l’utilisateur qui vous oblige à accéder à la ressource, utilisez le paramètre access_token et si le paramètre access_token a expiré, utilisez le paramètre refresh_token pour en obtenir un nouveau.

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

  1. Si vous n’avez pas de gestion de session, placez le access_token dans un cookie et utilisez-le comme une session. Ensuite, à chaque fois que l’utilisateur demande des pages à votre serveur Web, envoyez le fichier access_token. Votre serveur d’application pourrait actualiser access_token au besoin.

En comparant 1 et 2:

En 1, access_token et refresh_token voyagent uniquement sur le fil entre le serveur d’permissions (google dans votre cas) et votre serveur d’applications. Cela se ferait sur un canal sécurisé. Un pirate informatique pourrait détourner la session mais ils ne pourraient interagir qu’avec votre application Web. En 2, le pirate informatique pouvait supprimer l’access à access_token et former ses propres requêtes aux ressources auxquelles l’utilisateur avait donné access. Même si le pirate accède à access_token, il ne disposera que d’une courte fenêtre pour accéder aux ressources.

Dans tous les cas, le serveur refresh_token et clientid / secret ne sont connus que du serveur, ce qui rend impossible pour le navigateur Web un access à long terme.

Imaginons que vous implémentiez oauth2 et définissiez un long délai d’attente sur le jeton d’access:

Dans 1) Il n’y a pas beaucoup de différence ici entre un jeton d’access court et long car il est caché dans le serveur d’applications. Dans 2) quelqu’un pourrait obtenir le access_token dans le navigateur et l’utiliser ensuite 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. Stocker clientid / secret sur l’appareil et faire en sorte que le périphérique orchestre l’obtention d’un access aux ressources de l’utilisateur.

  2. Utilisez un serveur d’applications backend pour conserver le client / secret et faire en sorte qu’il soit orchestré. Utilisez le type access_token comme une sorte de clé de session et transmettez-le 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. Tout le monde peut décomstackr puis commencer à agir comme si c’était vous, avec la permission de l’utilisateur bien sûr. Les options access_token et refresh_token sont également en mémoire et peuvent être consultées sur un périphérique compromis, ce qui signifie que quelqu’un peut agir en tant qu’application sans que l’utilisateur fournisse ses informations d’identification. Dans ce scénario, la longueur de access_token ne change rien à la hackabilité, puisque refresh_token se trouve au même endroit que access_token. Dans 2) le client / secret ou le jeton de rafraîchissement sont compromis. Ici, la durée de l’expiration de access_token détermine la durée pendant laquelle un pirate peut accéder aux ressources des utilisateurs, s’il les obtient.

Longueur d’expiration

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

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

J’espère que ce post plutôt long est utile.

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

Les jetons d’actualisation expirent également mais ils sont supposés vivre beaucoup plus longtemps que le jeton d’access.

En plus des autres réponses:

Une fois obtenues, les jetons d’access 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 des jetons d’access (en supposant bien sûr que les jetons d’access soient de type “Bearer” (comme 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 dissortingbués et présentent généralement des niveaux de sécurité inférieurs à ceux des serveurs d’autorisation (configuration SSL / TLS inférieure, renforcement moindre, etc.). Les serveurs d’autorisation, d’autre part, sont généralement considérés comme des infrastructures de sécurité critiques et sont soumis à un durcissement plus sévère.

  • Les jetons d’access peuvent apparaître dans les traces HTTP, les journaux, etc. collectés de manière légitime à 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 (traqueurs de bogues, service-desk, etc.).

  • Les applications backend RS peuvent être externalisées à des tiers plus ou moins fiables.

Le jeton d’actualisation, en revanche, n’est généralement transmis que deux fois sur les fils, 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é (expire effectivement l’actualisation précédente). jeton). C’est une opportunité extrêmement limitée d’interception et de relecture.

Dernière pensée, Refresh Tokens offre très peu de protection, le cas échéant, contre les clients compromis.