Le jeton daccès a expiré

d’accès Lorsque votre service émet des jetons d’accès, vous devez prendre des décisions quant à la durée de vie des jetons. Malheureusement, il n’existe pas de solution globale pour chaque service. Les différentes options offrent différents compromis, vous devez donc choisir l’option (ou la combinaison d’options) qui correspond le mieux aux besoins de votre application.

Jetons d’accès de courte durée et jetons d’actualisation à longue durée de vie

Une méthode courante d’octroi de jetons consiste à utiliser une combinaison de jetons d’accès et de jetons d’actualisation pour une sécurité et une flexibilité maximales. La spécification OAuth 2.0 recommande cette option, et plusieurs des implémentations les plus importantes ont adopté cette approche.

En règle générale, les services utilisant cette méthode émettent des jetons d’accès qui durent de quelques heures à quelques semaines. Lorsque le service émet le jeton d’accès, il génère un jeton d’actualisation qui n’expire jamais et le renvoie également dans la réponse. (Notez que les jetons d’actualisation ne peuvent pas être émis à l’aide de l’octroi implicite.)

Lorsque le jeton d’accès expire, l’application peut utiliser le jeton d’actualisation pour obtenir un nouveau jeton d’accès. Il peut le faire en coulisses, et sans l’implication de l’utilisateur, de sorte que le processus est transparent pour l’utilisateur.

Le principal avantage de cette approche est que le service peut utiliser des jetons d’accès auto-encodés qui peuvent être vérifiés sans recherche dans la base de données. Cependant, cela signifie qu’il n’y a aucun moyen d’expirer ces jetons directement, donc à la place, les jetons sont émis avec un délai d’expiration court afin que l’application soit obligée de les actualiser continuellement, ce qui donne au service la possibilité de révoquer l’accès d’une application si nécessaire.

Du point de vue du développeur tiers, il est souvent frustrant de devoir faire face à jetons d’actualisation. Les développeurs préfèrent fortement les jetons d’accès qui n’expirent pas, car il y a beaucoup moins de code à gérer. Afin d’atténuer ces problèmes, les services intègrent souvent la logique d’actualisation du jeton dans leur SDK, afin que le processus soit transparent pour les développeurs.

En résumé, utilisez des jetons d’accès de courte durée et des jetons d’actualisation de longue durée lorsque :

• vous souhaitez utiliser des jetons d’accès auto-encodés
• vous souhaitez limiter le risque de fuite de jetons d’accès
• vous fournirez des SDK capables de gérer la logique d’actualisation de manière transparente pour les développeurs

Jetons d’accès de courte durée et aucun jeton

d’actualisation Si vous souhaitez vous assurer que les utilisateurs sont au courant des applications qui accèdent à leur compte, le service peut émettre des jetons d’accès de durée relativement courte sans jetons d’actualisation. Les jetons d’accès peuvent durer n’importe où à partir de l’application actuelle à quelques semaines. Lorsque le jeton d’accès expire, l’application est forcée de faire en sorte que l’utilisateur se connecte à nouveau, afin que vous, en tant que service, sachiez que l’utilisateur est continuellement impliqué dans la réautorisation de l’application.

En règle générale, cette option est utilisée par les services où il existe un risque élevé de dommages si une application tierce devait divulguer accidentellement ou malicieusement des jetons d’accès. En exigeant que les utilisateurs réautorisent constamment l’application, le service peut s’assurer que les dommages potentiels sont limités si un attaquant venait à voler des jetons d’accès du service.

En n’émettant pas de jetons d’actualisation, il est impossible pour les applications d’utiliser le jeton d’accès de manière continue sans que l’utilisateur ne soit devant l’écran. Les applications qui ont besoin d’un accès pour synchroniser continuellement les données ne pourront pas le faire avec cette méthode.

Du point de vue de l’utilisateur, il s’agit de l’option la plus susceptible de frustrer les gens, car il semblera que l’utilisateur doit continuellement réautoriser l’application.

En résumé, utilisez des jetons d’accès de courte durée sans jetons d’actualisation lorsque :

• vous souhaitez bénéficier d’une protection maximale contre le risque de fuite de jetons d’accès
• vous souhaitez forcer les utilisateurs à être conscients de l’accès tiers qu’ils accordent
• vous ne voulez pas que les applications tierces aient un accès hors ligne aux données des utilisateurs Jetons d’accès

non expirés

Les jetons d’accès qui n’expirent pas sont la méthode la plus simple pour les développeurs. Si vous choisissez cette option, il est important de tenir compte des compromis que vous faites.

Il n’est pas pratique d’utiliser des jetons auto-encodés si vous voulez pouvoir les révoquer arbitrairement. En tant que tel, vous devrez stocker ces jetons dans une sorte de base de données, afin qu’ils puissent être supprimés ou marqués comme non valides si nécessaire.

Notez que même si le service a l’intention d’émettre des jetons d’accès non expirés pour une utilisation normale, vous devrez toujours fournir un mécanisme pour les faire expirer dans des circonstances exceptionnelles, par exemple si l’utilisateur souhaite explicitement révoquer l’accès d’une application ou si un compte d’utilisateur est supprimé.

Les jetons d’accès qui n’expirent pas sont beaucoup plus faciles pour les développeurs qui testent leurs propres applications. Vous pouvez même prégénérer un ou plusieurs jetons d’accès non expirés pour les développeurs et les leur montrer sur l’écran des détails de l’application. De cette façon, ils peuvent immédiatement commencer à faire des requêtes d’API avec le jeton, et ne pas se soucier de la configuration d’un flux OAuth afin de commencer à tester votre API.

En résumé, utilisez des jetons d’accès qui n’expirent pas lorsque :

• vous disposez d’un mécanisme pour révoquer les jetons d’accès arbitrairement
• Vous n’avez pas un risque énorme si les jetons
• que vous souhaitez fournir sont divulgués Un mécanisme d’authentification simple pour vos développeurs
• Vous souhaitez que les applications tierces aient un accès hors ligne aux données des utilisateurs