JWT ou Opaque Token : Quel est le meilleur choix pour le M2M ?
Les JWT ou les Opaque Tokens peuvent tous deux servir de mécanismes d’authentification pour les communications Machine to Machine (M2M). Mais quel est le meilleur choix entre chaque solution ? Dans ce bref article, nous allons tenter de répondre à cette question.
Tout d’abord, nous devrions définir ce que sont le JWT et l’Opaque Token.
OAuth (Client Credentials)
Dans cet article, nous utiliserons OAuth pour les JWT (JSON Web Tokens) et les Opaque Tokens. Commençons par définir ce qu’est OAuth et quel grant_type utiliser pour les communications Machine to Machine.
OAuth (Open Authorization) est un protocole utilisé pour l’autorisation, permettant d’accorder à des applications tierces un accès limité aux ressources. Il permet un accès sécurisé aux API en offrant aux clients (applications) un moyen d’obtenir des jetons d’accès (access tokens) auprès de serveurs d’autorisation, qui sont ensuite utilisés pour s’authentifier et accéder aux ressources protégées.
Le grant_type Client Credentials est l’un des types d’autorisation définis par OAuth. Il est généralement utilisé lorsque le client (l’application) agit pour son propre compte, plutôt que pour le compte d’un utilisateur. Ce type d’autorisation est adapté à la communication machine-to-machine ou aux cas où aucune intervention de l’utilisateur n’est requise.
POST /token HTTP/1.1Host: authorization-server.comContent-Type: application/x-www-form-urlencoded
grant_type=client_credentials&client_id=abcd1234&client_secret=client_secret&scope=read write&audience=api_server
Dans cet exemple, le client envoie une requête POST au point de terminaison (endpoint) de jeton du serveur d’autorisation avec le paramètre grant_type=client_credentials. Le client inclut également son client_id et son client_secret dans la requête. Le serveur d’autorisation valide les identifiants du client et émet un jeton d’accès si le client est autorisé.
La réponse du serveur d’autorisation inclut un jeton d’accès que le client peut utiliser pour s’authentifier et accéder aux ressources protégées.
{ "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c", "token_type": "Bearer", "expires_in": 86400}JWT
Un JWT (JSON Web Token) est un mécanisme compact et autonome pour transmettre des informations de manière sécurisée entre les parties sous forme d’objet JSON. Dans le contexte de l’authentification API, un JWT sert généralement de jeton d’authentification. Il est signé numériquement pour vérifier son authenticité et son intégrité.
Opaque Token
Un jeton opaque (opaque token) est un type de jeton utilisé pour l’authentification et l’autorisation qui ne contient aucune information significative en soi. Au lieu de cela, il sert de référence ou d’identifiant à un enregistrement stocké côté serveur, où les informations réelles et les permissions associées au jeton sont conservées.
Dans le contexte de l’authentification OAuth, un jeton opaque est généralement émis par le serveur d’autorisation et peut être utilisé par le client pour accéder aux ressources protégées. Contrairement aux JWT, les jetons opaques ne contiennent aucune revendication (claim) directement dans le jeton lui-même, ce qui les rend moins descriptifs par eux-mêmes.
Veuillez noter que les jetons opaques peuvent être émis par des fournisseurs autres qu’OAuth, tels que des systèmes d’authentification personnalisés, ou être simplement une chaîne de caractères aléatoire connue du client et du serveur de ressources.
Avantages et Inconvénients
| Propriété | JWT | Opaque Token | API Token |
|---|---|---|---|
| Autonome Contient toutes les informations nécessaires dans le jeton lui-même, réduisant le besoin de recherches fréquentes en base de données. | ✅ | ❌ | ❌ |
| Stateless Contient toutes les informations pertinentes pour que les serveurs de ressources puissent les valider et les traiter. | ✅ | ❌ | ❌ |
| Format Standard Format standard utilisé facilitant l’analyse et l’inspection, aidant au débogage. | ✅ (JSON) | ❔ (Dépend de la solution) | ❌ |
| Taille de la charge utile Des tailles de jetons plus importantes peuvent impacter la charge réseau. | ❔ (Le JWT peut être plus grand selon les claims définis) | ✅ | ✅ |
| Exposition des informations Ne contient pas d’informations lisibles, réduisant le risque d’exposition des données. | ❌ | ✅ | ✅ |
| Charge du serveur Ne nécessite pas de validation côté serveur pour chaque requête, ce qui peut potentiellement augmenter la performance. | ✅ | ❌ | ❌ |
| Durée de vie du jeton (TTL) Expire après un certain temps, limitant ainsi la durée de l’impact en cas de fuite du jeton. | ✅ | ✅ | ❌ |
Facteurs de décision
Sécurité
Ici, la question principale concerne la sécurité des informations transmises entre le client et le serveur de ressources. Les JWT exposent les “claims” directement dans le jeton lui-même, lesquelles peuvent être lues par quiconque a accès au jeton. Cela peut constituer un risque de sécurité si des informations sensibles sont incluses dans le jeton. En revanche, les jetons opaques n’exposent aucune information directement, ce qui les rend plus sûrs en termes d’exposition des données.
Dans le contexte des communications Machine to Machine, où le client agit pour son propre compte, le risque d’exposition des données peut être plus faible par rapport aux scénarios d’authentification basés sur l’utilisateur. Le JWT peut ne pas contenir d’informations sensibles entre deux machines.
Facilité d’implémentation
Le JWT est un format standard largement utilisé et supporté par de nombreuses bibliothèques et frameworks. Cela facilite son implémentation et son intégration avec les systèmes existants. Les jetons opaques, en revanche, peuvent nécessiter des implémentations personnalisées ou une logique supplémentaire pour gérer la validation et le traitement des jetons.
Scalabilité
La nature autonome des JWT peut être bénéfique pour la scalabilité, car elle réduit le besoin de recherches fréquentes en base de données pour valider le jeton. Cela peut aider à améliorer les performances et à réduire la charge du serveur, en particulier dans les scénarios à fort trafic. Les jetons opaques, quant à eux, peuvent nécessiter une validation côté serveur pour chaque requête, ce qui peut impacter la scalabilité et les performances.
Les JWT peuvent être plus volumineux que les jetons opaques, ce qui peut impacter la charge réseau. Cependant, l’impact peut être négligeable dans de nombreux cas, surtout si l’on considère les avantages des jetons autonomes.
Conformité
Selon les exigences réglementaires ou les normes de l’industrie, un type de jeton peut être plus approprié que l’autre. Par exemple, si les réglementations sur la confidentialité des données exigent que les informations sensibles soient protégées, les jetons opaques peuvent être préférés pour éviter d’exposer les données directement dans le jeton.
Encore une fois, dans le contexte des communications Machine to Machine, le risque d’exposition des données peut être plus faible par rapport aux scénarios d’authentification basés sur l’utilisateur. Le choix entre JWT et jetons opaques doit être basé sur les exigences et les contraintes spécifiques du système.
Recommandation
De manière générale, les JWT sont un bon choix pour les communications Machine to Machine en raison de leur nature autonome et de leur facilité d’implémentation.
La question peut être différente avec l’authentification basée sur l’utilisateur, où le risque d’exposition des données est plus élevé et où les jetons opaques peuvent être préférés selon la situation.
Cependant, si vous n’avez pas de fournisseur OAuth, vous pouvez utiliser des jetons opaques comme solution simple. Les jetons opaques peuvent être générés par le client et validés par le serveur de ressources sans avoir besoin d’un serveur d’autorisation centralisé. Cela peut être utile dans des scénarios où un mécanisme d’authentification léger est nécessaire et où la complexité des JWT n’est pas justifiée.