Claims JWT et frontières d’autorisation

Les claims JWT sont pratiques parce qu’ils rapprochent des faits de la requête. Cette commodité devient dangereuse lorsqu’ils remplacent l’autorisation. Un jeton signé peut prouver qu’un émetteur a fait une déclaration à un instant donné. Il ne prouve pas que cette déclaration est encore vraie, que la ressource appartient au même tenant, ni qu’un utilisateur doit effectuer une action précise maintenant.

L’identité n’est pas l’autorisation

sub identifie un principal. scope ou roles décrivent de grands paniers de permissions. tenant_id peut décrire le tenant choisi à la connexion. Aucun de ces claims ne répond automatiquement à la question: "Cet utilisateur peut-il approuver cette facture?" La ressource demande encore des contrôles de propriété, de frontière tenant et parfois d’état. Les attaquants cherchent les endroits où un claim remplace une jointure base de données qui n’a jamais lieu.

Un bug fréquent apparaît dans les APIs multi-tenant: le handler fait confiance à tenant_id dans le jeton pour filtrer les enregistrements, mais la route accepte aussi un identifiant tenant ou compte dans le chemin. Si les valeurs divergent, le système doit rejeter. Préférer silencieusement l’une crée un comportement confus. Faire confiance au chemin crée un contournement d’autorisation.

Les claims vieillissent mal

Rôles, niveaux de plan, appartenance à une organisation et droits de fonctionnalités peuvent changer pendant que le jeton reste valide. Si les access tokens vivent une heure, retirer un rôle admin peut prendre une heure à compter sauf si l’API vérifie l’état courant. Pour des lectures peu risquées, c’est parfois acceptable. Pour la facturation, les exports, les actions admin et les opérations destructrices, les claims périmés le sont rarement.

Une frontière pratique

Utilise les JWT pour les faits d’authentification et le routage grossier: émetteur, sujet, audience, expiration, identifiant de session et peut-être un scope compact. Utilise des contrôles serveur pour l’autorisation sur les ressources. Si la performance compte, cache les décisions d’autorisation avec TTL court et invalidation explicite plutôt que de mettre chaque permission dans le jeton.

Tester l’abus de claims

Pendant un pentest, modifie un claim à la fois et observe les changements d’accès aux objets. Change tenant_id, org_id, scope, role, email_verified et les feature flags. Garde une signature valide si tu contrôles un émetteur de test, ou utilise des jetons peu privilégiés sur plusieurs endpoints pour voir où les claims sont décodés avant vérification. GraphQL mérite une attention particulière, car les resolvers appliquent parfois l’autorisation de manière inégale.

Règle de conception

Un JWT doit porter assez d’information pour identifier l’appelant et choisir le bon vérificateur, pas assez pour contourner le modèle d’autorisation. Quand un claim influence l’argent, les frontières de données ou le pouvoir admin, l’API doit pouvoir expliquer pourquoi elle lui a fait confiance à cet instant.