Quelques scénarios peuvent aider à illustrer le but des jetons d'accès et de rafraîchissement et les compromis techniques dans 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 plusieurs options :
- si vous avez votre propre gestion de session, stockez à la fois l'access_token et le refresh_token en fonction de votre identifiant de session dans session state sur votre service session state. Lorsqu'une page est demandée par l'utilisateur qui vous demande d'accéder à la ressource, utilisez l'access_token et si l'access_token a expiré, utilisez le refresh_token pour obtenir le nouveau.
Imaginons que quelqu'un réussisse à détourner votre session. La seule chose qui soit possible est de demander vos pages.
- si vous ne disposez pas d'une gestion de session, mettez la clé d'accès dans un cookie et utilisez-le comme session. Ensuite, chaque fois que l'utilisateur demande des pages à votre serveur web, il envoie l'access_token. Votre serveur d'applications peut rafraîchir l'access_token si nécessaire.
Comparaison entre 1 et 2 :
En 1, access_token et refresh_token ne voyagent que sur le fil entre le serveur d'autorisation (google dans votre cas) et votre serveur d'application. Cela se fait sur un canal sécurisé. Un pirate pourrait détourner la session, mais il ne pourrait interagir qu'avec votre application Web. En 2, le pirate pourrait s'emparer de l'access_token et formuler ses propres demandes aux ressources auxquelles l'utilisateur a donné accès. Même si le pirate met la main sur le code d'accès, il ne disposera que d'une courte fenêtre pour accéder aux ressources.
Dans tous les cas, le refresh_token et le clientid/secret ne sont connus que du serveur, ce qui rend impossible l'obtention d'un accès à long terme à partir du navigateur Web.
Imaginons que vous implémentez oauth2 et que vous définissiez un long délai d'attente pour le jeton d'accès :
En 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'application. En 2) quelqu'un pourrait obtenir le jeton d'accès dans le navigateur et ensuite l'utiliser pour accéder directement aux ressources de l'utilisateur pendant une longue période.
Scénario mobile
Sur le mobile, il y a deux scénarios que je connais :
-
Stockez le clientid/secret sur le dispositif et faites en sorte que le dispositif orchestre l'obtention de l'accès aux ressources de l'utilisateur.
-
Utilisez un serveur d'applications dorsal pour contenir le client/secret et laissez-le faire l'orchestration. Utilisez l'access_token comme une sorte de clé de session et faites-la passer entre le client et le serveur d'applications.
Comparaison entre 1 et 2
En 1) Une fois que vous avez le clientid/secret sur le dispositif, ils ne sont plus secrets. N'importe qui peut décompiler et ensuite commencer à agir comme s'il était vous, avec la permission de l'utilisateur bien sûr. L'access_token et le refresh_token sont également en mémoire et pourraient ê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 l'access_token ne fait aucune différence pour le piratage puisque le refresh_token se trouve au même endroit que l'access_token. Dans 2) le clientid/secret et le refresh_token sont compromis. Dans ce cas, la durée d'expiration de l'access_token détermine combien de temps un pirate peut accéder aux ressources de l'utilisateur, s'il s'en empare.
Durées d'expiration
La durée d'expiration de votre code d'accès dépend de ce que vous sécurisez avec votre système d'authentification. S'il s'agit de quelque chose de particulièrement précieux pour l'utilisateur, elle doit être courte. S'il s'agit de quelque chose de moins précieux, elle peut être plus longue.
Certaines personnes comme Google n'expirent pas le refresh_token. D'autres, comme stackflow, le font. La décision sur l'expiration est un compromis entre la facilité d'utilisation et la sécurité. La durée du jeton de rafraîchissement est liée à la durée de retour de l'utilisateur, c'est-à-dire que le rafraîchissement doit correspondre à la fréquence de retour de l'utilisateur sur votre application. Si le jeton de rafraîchissement n'expire pas, la seule façon de le révoquer est de le révoquer explicitement. Normalement, une connexion ne peut pas être révoquée.
J'espère que cet article assez long vous sera utile.
