Expiration du jeton Web JSON
Sur la plupart des didacticiels JWT (jeton Web JSON) (par exemple: this et this ), une fois validé, vous pouvez utiliser le jeton entrant pour obtenir des informations client sans les valider à partir de la base de données.
Ma question est, comment la situation d'utilisateur invalide est-elle maintenue alors? Ce que je veux dire, c’est, disons un client vient de recevoir un jeton JWT qui expire dans une semaine. Mais pour une raison très spécifique, disons que nous avons décidé d’invalider l’utilisateur et ne souhaitons pas qu’il accède à notre API. Mais cet utilisateur a toujours un jeton valide et l'utilisateur peut accéder à l'API.
Bien sûr, si nous effectuons un aller-retour vers DB pour chaque demande, nous pouvons valider si le compte est valide ou non. Ma question est la suivante: quel est le meilleur moyen de prendre en charge ce type de situation pour les jetons de longue durée.
Merci d'avance.
Le flux OAuth que vous utilisez dans votre question n’est pas clair, ni si vous faites référence à OpenID Connect plutôt qu’Oauth.
Envisagez d'utiliser des jetons d'actualisation et d'expiration beaucoup plus courte sur votre jeton d'accès, par exemple. 30 min.
Dans ce scénario, l'utilisateur (resource owner) ne doit pas rester authentifié et votre API (Resource Server) ne doit pas vérifier que l'utilisateur est toujours valide pour chaque requête.
Une fois le jeton d'accès arrivé à expiration, votre client (application appelant votre API) doit contacter votre base de données (Authorisation Server) et échanger son jeton d'actualisation contre un nouveau jeton d'accès - et généralement un nouveau jeton d'actualisation - à condition que l'utilisateur reste un utilisateur valide sur votre base de données et l'utilisateur n'a pas révoqué l'accès de l'application client à ses données sur l'API.
Vous pouvez également utiliser la révocation de jetons comme suggéré dans une autre réponse si votre serveur d'autorisations le permet, mais j'essaierais d'actualiser les jetons et les jetons d'accès de courte durée, car il est beaucoup plus facile à mettre en œuvre et ne pollue pas votre API avec des problèmes d'authentification/autorisation d'utilisateur. Le travail est mieux effectué par un serveur d’authentification.
RFC 7009 spécifie OAuth 2.0 révocation de jeton. En gros, vous avez un noeud final sur lequel vous pouvez révoquer les access_tokens.
C'est le principal problème lorsque vous utilisez JWT. La meilleure approche dans ce cas consiste donc à créer une liste noire sur votre passerelle. Ce n'est pas la meilleure solution du point de vue de la sécurité mais ce n'est qu'une bonne solution si vous utilisez JWT.