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:
- 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.
- 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:
Stockez l'ID client / secret sur l'appareil et demandez à l'appareil d'orchestrer l'accès aux ressources de l'utilisateur.
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.