04. Claims et profil de jeton d’accès

Comprendre le mécanisme

Un profil de jeton d’accès précise les claims requis, leurs types et leur sens pour une API. Issuer indique l’autorité attendue, audience les destinataires, subject une identité dans le contexte de cet émetteur. Des scopes décrivent un vocabulaire d’accès du protocole ; leur présence ne remplace pas la propriété d’une ressource. Une API ne doit pas réutiliser un validateur générique sans préciser ses attentes.

Raisonner et vérifier

Construisez une matrice : nom du claim, présence, type, valeurs admissibles, source de confiance et décision associée. Les dates numériques se comparent avec une horloge maîtrisée et une tolérance bornée, documentée plutôt qu’illimitée. Distinguez expiration du token et fin d’une permission métier. Un compte désactivé ou un objet transféré peut rendre une action interdite pendant la durée cryptographique du token.

Émetteur exact

iss doit correspondre à l’émetteur attendu. Le contrat de confiance fixe les autorités acceptées. Comparez iss à un fournisseur configuré selon les règles du profil. Ne téléchargez pas sa configuration depuis n’importe quelle valeur reçue ; cette valeur est initialement une entrée hostile.

Audience attendue

aud doit inclure le consommateur prévu selon le profil. La destination du token doit être vérifiée. Vérifiez que aud désigne votre API, sous la forme prescrite. Un token d’une autre API peut avoir une signature correcte et un sujet connu sans être acceptable pour ce consommateur.

Expiration

exp numérique représente une limite temporelle selon le profil. Type et comparaison temporelle sont nécessaires. Contrôlez le type numérique et la borne temporelle définie. Un exp absent, texte ou expiré doit suivre la règle du profil, sans conversion permissive inventée par un helper local.

Horloge

Une horloge injectée rend les limites testables. Le temps peut être un paramètre contrôlé. Injectez une horloge dans les tests pour essayer juste avant, à la borne et après exp ou nbf. Vous obtenez une preuve reproductible sans sommeil ni dépendance à la vitesse de la machine.

Tolérance

La tolérance temporelle doit être bornée. Une marge illimitée annule la limite recherchée. Une petite marge peut traiter un écart d’horloge prévu. Fixez-la explicitement et testez sa borne ; une tolérance très large transforme un mécanisme d’expiration court en fenêtre d’usage beaucoup plus longue.

Scope et objet

Un scope ne remplace pas les droits sur un objet. La politique métier doit préciser le périmètre. Un scope reservations:read permet une catégorie d’opération dans le contrat. Il ne prouve pas que chaque réservation appartient au sujet ; ajoutez un contrôle de tenant et de relation à l’objet.

Sujet contextualisé

Le sujet s’interprète dans son contexte d’émetteur. Le namespace d’identité dépend du contrat. Deux émetteurs peuvent utiliser la même valeur sub pour des personnes différentes. Identifiez un compte avec le contexte de son fournisseur et les règles de liaison maîtrisées par l’application.

Désactivation

Un compte désactivé peut exiger un contrôle supplémentaire. La validité temporelle du token et l’état métier diffèrent. Si un compte suspendu doit être refusé immédiatement, un token autonome peut demander un état supplémentaire. Définissez le délai attendu et vérifiez chaque consommateur, caches compris.

Contrat complet

Les claims requis doivent être explicités. Les absences et types doivent avoir des règles définies. Documentez signature, algorithmes, clé, iss, aud, types et claims temporels requis. Une liste de champs lue par le code n’est pas encore une politique d’acceptation cohérente.

Refus signé

Un test négatif doit utiliser aussi des signatures valides. Une signature correcte isole le contrôle de destination. Pour tester l’audience, utilisez un token correctement signé avec la mauvaise audience. Sinon, un rejet cryptographique préalable pourrait masquer le fait que le contrôle d’audience n’est jamais appliqué.

Atelier guidé : lire, expliquer et vérifier le code

{
  "expectedAudience": "reservation-api",
  "verifiedClaims": {
    "iss": "https://identity.example.test",
    "aud": "stock-api",
    "exp": 4102444800
  }
}

Le token illustré a pour audience stock-api alors que le consommateur attend reservation-api. Cette différence suffit à refuser selon le profil, malgré la signature et la date supposées valides. Contrôlez l’absence d’appel métier puis ajoutez un token identique avec l’audience admise pour vérifier le chemin nominal.

La validation du profil ne se réduit pas à la signature. Le consommateur n’est pas la destination annoncée. La date ne corrige pas le destinataire. Modifier les claims ne rend pas l’émission légitime.

Travail pratique : Produisez des tokens correctement signés mais avec mauvais issuer, mauvaise audience, expiration passée et date de mauvais type.

Critères de correction : Injectez une horloge fixe. Les quatre cas sont refusés et le token nominal réussit. Testez ensuite l’accès à une réservation tierce pour démontrer l’autorisation distincte.

JWT : de la preuve cryptographique au droit sur l’objet

Un émetteur reconnu ne rend pas acceptable tout token qui mentionne son nom. Le validateur doit choisir une clé admise, imposer l’algorithme autorisé et vérifier la signature avec une bibliothèque configurée pour ce profil.

Il contrôle ensuite émetteur, audience, claims nécessaires et validité temporelle avec leurs types et la tolérance prévue. Une signature correcte destinée à une autre API reste un motif de refus. Les claims ne doivent pas produire une identité de confiance avant la réussite de ces étapes.

Enfin, une identité ou un scope ne donne pas automatiquement accès à tous les objets. Chargez la ressource dans la portée autorisée et vérifiez l’opération métier. Pour chaque contrôle, utilisez une fixture qui passe les étapes précédentes : token signé avec mauvaise audience, token expiré et token valide d’un autre propriétaire. Vérifiez refus avant effet et un cas nominal, sans conserver les tokens réels dans les logs.

Points de vigilance : L’authenticité, le destinataire, la période de validité et l’autorisation répondent à des questions distinctes. Décoder ne prouve pas l’authenticité du payload. Le token non fiable ne doit pas pouvoir imposer une source arbitraire de clés de confiance. La présence d’un rôle ne prouve pas le droit d’agir sur une ressource donnée.

SCA et liaison dynamique : le montant authentifié doit correspondre

Le cas est explicitement une opération UE soumise à la SCA avec liaison dynamique au montant et au bénéficiaire. Dans ce périmètre, le code est lié aux données de l’opération présentée au payeur ; il ne représente pas une autorisation générale de payer un montant choisi ultérieurement.

Si le montant change, l’ancien code ne doit pas être accepté comme preuve pour la nouvelle opération. Reprenez le parcours applicable avec le PSP et présentez les données cohérentes au payeur. Le backend doit relier état d’authentification et version de l’intention pour éviter une modification tardive après validation.

Testez un montant inchangé et un montant modifié, puis vérifiez l’absence de traitement fondé sur l’ancienne preuve. La réussite d’une signature JWT ou d’une session ne remplace pas cette liaison. Les exemptions et autres flux ont des conditions propres ; elles ne sont pas une hypothèse implicite permettant d’éluder le cas posé.

Points de vigilance : Le code est lié aux données de transaction dans le scénario décrit. Aucune tolérance générale de ce type n’est donnée par cette règle de liaison dynamique. Un changement du montant invalide le code associé à l’opération initiale ; traiter le nouveau parcours selon les règles applicables. Une exemption ne se décide pas par un flag arbitraire ; son éligibilité dépend du cadre applicable.