Pourquoi les jetons d'accès expirent-ils?
Je commence tout juste à travailler avec Google API et OAuth2. Lorsque le client autorise mon application, un "jeton d'actualisation" et un "jeton d'accès" de courte durée sont attribués. Maintenant, chaque fois que le jeton d'accès expire, je peux POST mon jeton d'actualisation à Google et ils me donneront un nouveau jeton d'accès.
Ma question est la suivante: quel est l'objectif de l'expiration du jeton d'accès? Pourquoi ne peut-il pas y avoir simplement un jeton d'accès durable au lieu du jeton d'actualisation?
De même, le jeton d'actualisation expire-t-il?
Voir tilisation de 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 à la mise en œuvre, 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 supports qui sont très faibles du point de vue de la sécurité. En les rendant éphémères et nécessitant une actualisation, ils limitent le temps pendant lequel un attaquant peut abuser d'un jeton volé.
- Les déploiements à grande échelle ne veulent pas effectuer une recherche de base de données à chaque appel d'API. Ils émettent donc un jeton d'accès auto-codé qui peut être vérifié par déchiffrement. Toutefois, cela signifie également qu’il n’ya 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 du client, ce qui le renforce. Contrairement aux jetons d'accès ci-dessus, il est généralement implémenté avec une recherche dans la base de données.
Quelques scénarios peuvent aider à illustrer l'objectif de l'accès et de l'actualisation des jetons et les compromis en matière d'ingénierie lors de la conception d'un système oauth2 (ou de tout autre système d'authentification):
Scénario d'application Web
Dans le scénario de l'application Web, vous avez plusieurs options:
- si vous avez votre propre gestion de session, enregistrez l'état access_token et refresh_token avec votre identifiant de session dans l'état de session sur votre service d'état de session. Lorsqu'une page demandée par l'utilisateur nécessitant que vous accédiez à la ressource, utilisez access_token et, si ce dernier a expiré, utilisez refresh_token pour obtenir le nouveau.
Imaginons que quelqu'un réussisse à détourner votre session. La seule chose possible est de demander vos pages.
- si vous n'avez pas de gestion de session, insérez le paramètre access_token dans un cookie et utilisez-le comme session. Ensuite, chaque fois que l'utilisateur demande des pages de votre serveur Web, envoyez le code d'accès_token. Votre serveur d'application peut actualiser le code d'accès si besoin est.
En comparant 1 et 2:
Dans 1, access_token et refresh_token se déplacent uniquement par le réseau entre le serveur de création (Google dans votre cas) et votre serveur d'applications. Cela se ferait sur un canal sécurisé. Un pirate informatique pourrait pirater la session, mais il ne pourrait interagir qu'avec votre application Web. En 2, le pirate informatique pourrait enlever le code d'accès et donner ses propres requêtes aux ressources auxquelles l'utilisateur a accordé l'accès. Même si le pirate récupère le code d'accès, il n'aura qu'une courte fenêtre dans laquelle il pourra accéder aux ressources.
Quoi qu'il en soit, refresh_token et 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 que vous définissiez un délai d’attente trop long 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 puisqu'il est caché dans le serveur d'applications. En 2) quelqu'un pourrait obtenir le code d'accès_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 deux scénarios:
Stockez le clientid/secret sur le périphérique et laissez-le orchestrer pour obtenir un accès aux ressources de l'utilisateur.
Utilisez un serveur d'applications principal pour contenir le clientid/secret et lui confier l'orchestration. Utilisez access_token comme une sorte de clé de session et transmettez-la entre le client et le serveur d'applications.
Comparer 1 et 2
Dans 1) Une fois que vous avez clientid/secret sur l'appareil, ils ne sont plus secrets. N'importe qui peut décompiler et ensuite commencer à agir comme s'il était vous-même, avec la permission de l'utilisateur bien sûr. Access_token et refresh_token sont également en mémoire et peuvent être consultés sur un appareil compromis, ce qui signifie que quelqu'un pourrait agir en tant qu'application sans que l'utilisateur ne donne ses informations d'identification. Dans ce scénario, la longueur de access_token n'a aucune incidence sur l'aptitude au piratage étant donné que refresh_token se trouve au même endroit que access_token. En 2) le clientid/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 informatique peut accéder aux ressources des utilisateurs, le cas échéant.
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 devrait être bref. Quelque chose de moins précieux, ça peut être plus long.
Certaines personnes comme Google n'expirent pas le refresh_token. Certains comme stackflow le font. La décision sur l'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.-à-d. Réglez l'actualisation sur la fréquence à laquelle l'utilisateur revient dans votre application. Si le jeton d'actualisation n'expire pas, la révocation explicite est la seule façon de les révoquer. Normalement, une connexion ne serait pas révoquée.
J'espère que ce poste plutôt long est 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 réexécution de jetons d'accès (en supposant bien sûr que les jetons d'accès sont de type "porteur" (comme défini dans le RFC6750 initial).
Exemples de ces risques, dans la vie réelle:
Les serveurs de ressources sont généralement des serveurs d'applications distribués et présentent généralement des niveaux de sécurité inférieurs à ceux des serveurs d'autorisations (configuration SSL/TLS plus faible, moins de renforcement, etc.). Les serveurs d’autorisation, d’autre part, sont généralement considérés comme une infrastructure de sécurité essentielle et sont soumis à un durcissement plus sévère.
Les jetons d'accès peuvent apparaître dans les traces HTTP, les journaux, etc., qui sont légitimement collectés à 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 (dépisteurs de bogues, service desk, etc.).
Les applications backend RS peuvent être sous-traitées à des tiers plus ou moins dignes de confiance.
Le jeton de rafraîchissement, quant à lui, est généralement transmis uniquement deux fois par le biais des câbles, et toujours entre le client et le serveur d'autorisations: une fois obtenu par le client, et une fois lorsqu'il est utilisé par le client lors de l'actualisation ("expire" effectivement le jeton d'actualisation précédent). Il s'agit d'une drastiquement possibilité limitée d'interception et de rejeu.
Dernière pensée, les jetons de rafraîchissement offrent très peu de protection, le cas échéant, contre les clients compromis.
C'est essentiellement une mesure de sécurité. Si votre application est compromise, l'attaquant n'aura accès qu'au jeton d'accès éphémère et n'aura 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.