Pourquoi le décodage des JWS n'est que le point d'entrée
Dans les architectures d'identité modernes, en particulier OAuth 2.0 et OpenID Connect, les jetons signés sont souvent considérés comme des "conteneurs de confiance" qui peuvent être transmis entre les services. Mais pour les ingénieurs en sécurité, les red teamers et les chercheurs en sécurité de l'IA, un JWS est mieux compris comme une entrée compacte, contrôlée par l'attaquant, qui se situe à l'intersection de la cryptographie et de la logique d'entreprise. La capacité d'effectuer un décodage de la signature web json n'est pas l'objectif ; c'est l'instrumentation qui vous permet de raisonner sur ce que le vérificateur pense qu'il valide, ce que l'application en fait pour l'autorisation, et quelles parties du jeton sont traitées comme une configuration plutôt que comme des données non fiables.
Cette distinction est importante car la "sécurité des jetons" n'est pas une propriété du format des jetons. C'est une propriété du pipeline de vérification et de validation des demandes-sélection de l'algorithme, sélection de la clé, contrôles de l'émetteur/du public, réclamations basées sur le temps et, de manière critique, comment le code en aval utilise les réclamations une fois qu'il les a obtenues. Dès lors qu'un système traite les revendications décodées comme la "vérité" avant que la vérification ne soit terminée (ou même exécutée), le jeton cesse d'être une limite de sécurité et devient un paramètre contrôlé par l'utilisateur.
L'ingénierie derrière la chaîne : Base64url sans remplissage
Lorsque les gens disent "décoder un JWS", ce qu'ils font généralement, c'est inverser une étape d'encodage base64url. Dans la sérialisation compacte de JWS, chacun des trois segments est encodé en base64url, en utilisant l'alphabet URL-safe et en omettant généralement les éléments suivants = rembourrage. Le RFC 7515 définit le format compact et utilise explicitement le format BASE64URL(...) pour la construction de l'en-tête et de la charge utile, puis concatène avec . séparateurs. (Rédacteur du RFC)
La convention "no padding" semble mineure jusqu'à ce que vous construisiez des outils ou analysiez le trafic capturé à grande échelle. De nombreuses routines génériques base64 partent du principe que le padding est présent et, en cas d'absence de padding, elles génèrent des erreurs ou des résultats ambigus. Un décodeur robuste doit réajuster le padding de manière déterministe et utiliser une routine de décodage compatible avec base64url, sinon votre analyse devient non reproductible, en particulier lorsque vous avez affaire à des jetons malformés ou intentionnellement corrompus pendant le fuzzing.
JWS vs JWT : ce que chaque point signifie réellement
Un jeton JWS Compact est toujours :
BASE64URL(header) . BASE64URL(payload) . BASE64URL(signature)
Le troisième segment n'est pas "hexagonal". Il s'agit de la base64url des octets de signature (ou MAC). Considérez-le comme opaque, à moins que vous ne procédiez à une vérification ou à un triage cryptographique.
JWT (RFC 7519) est une convention d'ensemble de revendications qui est généralement incluse dans la charge utile JWS, ce qui explique pourquoi les gens confondent "JWT" et "JWS". La RFC 7519 définit les revendications enregistrées comme iss, sous, aud, expet nbfet décrit comment ces demandes sont représentées sous la forme d'un objet JSON. (IETF Datatracker)
En pratique, cela signifie qu'une étape de décodage uniquement peut vous dire ce que le jeton revendicationsmais il ne peut pas vous dire si ces affirmations sont fondées ou non. vrai. La vérité n'apparaît qu'après la vérification de la signature et la validation de la demande.
L'en-tête est la surface d'attaque : alg, enfant, jku en tant qu'intrants non fiables
Dans les systèmes bien conçus, l'en-tête du jeton est une métadonnée qui aide le vérificateur à sélectionner une stratégie de vérification connue et efficace. Dans les systèmes mal conçus, l'en-tête devient un canal de configuration contrôlé par l'attaquant. C'est pourquoi, lors d'une décodage de la signature web jsonDe nombreux professionnels se concentrent d'abord sur l'en-tête.
Les alg est particulièrement sensible car elle peut influencer la méthode de vérification invoquée. La confusion d'algorithme (également appelée confusion de clé) se produit lorsqu'un attaquant peut forcer le serveur à vérifier un JWT en utilisant un algorithme différent de celui prévu par le développeur, ce qui peut permettre de créer de faux jetons sans connaître la clé de signature du serveur. La Web Security Academy de PortSwigger décrit clairement cette classe et l'associe à une mauvaise configuration ou à une mauvaise gestion des choix d'algorithmes. (PortSwigger)
Les enfant n'est pas de la cryptographie, mais de la récupération de clés. Si le enfant Si l'on ne tient pas compte des influences des chemins d'accès aux fichiers, des requêtes de bases de données, des clés de cache ou des résolveurs dynamiques sans liste d'autorisation stricte, cela devient une surface d'injection générale à l'intérieur de la limite de gestion des clés.
Les jku est encore plus dangereux lorsqu'il est mal utilisé. Si un serveur récupère un JWKS à partir d'une URL spécifiée par l'en-tête du jeton (ou à partir d'une variante insuffisamment contrainte), l'attaquant peut tenter de remplacer l'ancre de confiance en orientant le vérificateur vers des clés contrôlées par l'attaquant. Même lorsqu'un système "ne récupère que du HTTPS", l'absence de listes d'autorisation strictes, de liaison avec l'émetteur, de politique de mise en cache et de pistes d'audit transforme la récupération des clés en un problème de chaîne d'approvisionnement, et non en un problème de cryptographie.
Un décodeur hors ligne de niveau production en Python (décodage uniquement, sécurité du remplissage)
Les débogueurs de jetons basés sur le Web sont pratiques, mais ils sont souvent une mauvaise idée dans le cadre d'un travail de sécurité professionnel. Les jetons peuvent contenir des identifiants sensibles, des courriels, des identifiants de locataires internes ou même des informations confidentielles intégrées. Vous voulez un outil hors ligne, scriptable, déterministe et sûr pour les entrées malformées. L'implémentation ci-dessous ne "vérifie" intentionnellement rien ; elle décode seulement ce qui est présent et rend les modes d'échec observables.
import base64
import json
from typing import Any, Dict, Tuple, Optional
def _b64url_decode(data : str) -> bytes :
# RFC 7515 base64url omet généralement le padding "=" ; rétablissez-le de manière déterministe.
pad = (-len(data)) % 4
return base64.urlsafe_b64decode((data + "=" * pad).encode("ascii"))
def _parse_json(b : bytes) -> Tuple[Optional[Dict[str, Any]], Optional[str]] :
try :
return json.loads(b.decode("utf-8")), None
except Exception as e :
return None, f"{type(e).__name__} : {e}"
def jws_decode(token : str) -> Dict[str, Any] :
parts = token.split(".")
if len(parts) != 3 :
return {"error" : "Format compact JWS non valide (3 parties attendues)", "parts" : len(parts)}.
header_b = _b64url_decode(parts[0])
payload_b = _b64url_decode(parts[1])
header, he = _parse_json(header_b)
payload, pe = _parse_json(payload_b)
out : Dict[str, Any] = {
"header_raw" : header_b.decode("utf-8", errors="replace"),
"payload_raw" : payload_b.decode("utf-8", errors="replace"),
"signature_b64url_sample" : parts[2][:16] + "..."
}
si l'en-tête n'est pas None :
out["header"] = header
sinon :
out["header_error"] = he
si payload n'est pas None :
out["payload"] = payload
sinon : out["payload_error"] = he
out["payload_error"] = pe
retourner out
Cela est conforme à l'utilisation de base64url de la RFC 7515 (et au fait que JWS compact est conçu pour les contextes d'en-tête URL/HTTP), tout en vous offrant un comportement stable lorsque le jeton est malformé, tronqué ou intentionnellement altéré. (Rédacteur du RFC)
Le fossé critique : décodage et vérification (et le vrai modèle de bogue)
L'erreur de sécurité la plus persistante concernant les JWS/JWT consiste à confondre décodage et vérification. Le décodage est un formatage réversible ; la vérification est une validation cryptographique et l'application d'une politique.
Dans les incidents réels, le modèle d'échec courant est "utiliser avant de vérifier" plutôt qu'une course littérale. Une application décode le jeton, lit rôle, user_id, locataireou scope, and makes authorization decisions before signature verification and claim validation are conclusively enforced. The OWASP guidance on JWT testing highlights how mis-handling algorithm expectations and verification logic enables high-impact attacks, including confusion between asymmetric and symmetric verification flows. (Fondation OWASP)
Even if the signature is valid, a token still needs claim validation. RFC 7519 defines aud as the audience claim, and notes that if the principal processing the token does not identify itself as an intended audience, the token must be rejected when aud is present. (IETF Datatracker) That’s a reminder that cryptographic validity is not equivalent to contextual validity.
Advanced exploitation: beyond “alg: none”
The “alg: none” narrative is historically important, but most modern libraries block it by default. The more interesting failures today tend to fall into two buckets: implementation flaws in crypto providers, and complex logic bypasses caused by flexible verification pipelines.
Psychic Signatures (CVE-2022-21449): when ECDSA verification lies
CVE-2022-21449—popularized as “Psychic Signatures”—is a severe Java cryptography vulnerability where ECDSA signature verification could be bypassed under certain conditions in affected Java versions (notably introduced in Java 15 and fixed in the April 2022 CPU). Analyses emphasize how dramatically it weakens systems relying on ECDSA signatures, including scenarios involving ECDSA-signed JWTs or WebAuthn mechanisms. (Neil Madden)
The most important lesson for token security is not the cleverness of the bypass; it’s the operational reality that “I chose ES256” is not a guarantee. Your runtime version, security provider implementation, and patch state are part of your threat model. Security teams should treat “crypto provider regressions” as first-class risks, with explicit patch SLAs and regression tests that exercise verification against malformed signatures.
Algorithm confusion / key confusion: when the server lets the token pick the rules
Algorithm confusion attacks occur when the verifier allows the token to influence which algorithm is used for verification, and the key handling is not separated cleanly between asymmetric and symmetric modes. PortSwigger notes that if this case isn’t handled properly, attackers may forge valid JWTs containing arbitrary values without knowing the server’s secret signing key. (PortSwigger)
In practice, the defense is conceptually simple but frequently missed: never allow “algorithm agility” at the boundary where authentication decisions are made. If your service expects RS256, you enforce RS256. You do not “accept whatever alg is in the header and see if it validates.”
Header-driven key retrieval: enfant/jku as verification supply chain
Once you accept that the header is attacker input, you also accept that key selection is part of your attack surface. A enfant should map to a pre-defined allowlist of keys, not to arbitrary key material fetched, loaded, or constructed at runtime. A jku should never allow a token to redefine where trust anchors come from. If you do support JWKS fetching for OIDC, it should be bound to a trusted issuer configuration and hardened with allowlists, caching, and monitoring.
Hardening strategies that survive production drift
A defense-in-depth approach to JWS validation tends to look boring on paper, but it is exactly what prevents the majority of token failures.
You explicitly pin accepted algorithms and require the verifier to enforce that the expected algorithm was used. OWASP’s JWT guidance for Java makes this point directly as a preventive measure. (Série d'aide-mémoire de l'OWASP)
You validate issuer and audience consistently. RFC 7519’s definitions for registered claims are not academic; they exist because “valid signature, wrong context” is a common class of failures. In particular, audience mismatches are one of the easiest ways to accidentally accept a token minted for a different service. (IETF Datatracker)
You treat key IDs as data, not as a lookup query. A enfant should resolve through a bounded mapping—KMS alias, static key registry, or tightly controlled key store—not a filesystem path or a database query built from untrusted input.
You patch crypto runtimes aggressively and test against known catastrophic classes. CVE-2022-21449 exists as a reminder that “correct algorithm choice” cannot compensate for broken verification implementations. (Neil Madden)
You monitor anomalies that hint at active probing. Large volumes of base64url padding errors, repeated invalid tokens, or high churn in enfant values can indicate ongoing fuzzing or confusion attempts. Monitoring won’t fix the bug, but it can shorten detection time and help you correlate suspicious activity with specific endpoints and verifiers.
Automating the verification logic audit: where Penligent can fit
In real environments, the hard part is not decoding a token once. It’s discovering where tokens are accepted, identifying which services enforce which verification rules, and proving whether downstream authorization depends on decoded claims prematurely. That “decode → interpret → mutate → validate impact” loop is repetitive, and it is exactly the kind of work modern AI-assisted security platforms can help industrialize.
A platform like Penligent can be positioned credibly as an automation layer for token-centric testing: it can perform offline decoding to classify tokens and extract high-signal fields (issuer, audience, scopes, roles), infer likely verification stacks from response behavior and service fingerprints, and then systematically test for policy drift—algorithm allowlist failures, inconsistent issuer/audience enforcement across microservices, and unsafe key selection patterns. The value is not “magic breaking tokens,” but repeatable evidence generation and continuous regression checks that catch subtle verification regressions before they ship.
If you treat JWS verification as a security-critical API boundary, then an AI-driven workflow is most powerful when it helps you ensure that boundary stays consistent across releases, environments, and service owners.
Conclusion
L'ordre de décodage de la signature web json is the starting line, not the finish line. Decoding gives you observability, but security comes from strict verification and claim validation, disciplined key management, and resilient runtime hygiene.
From catastrophic crypto-provider failures like “Psychic Signatures” (CVE-2022-21449) to algorithm confusion and header-driven key supply chain risks, JWS security is a system property. Teams that combine careful manual analysis with automation that detects verification drift can keep their authentication layers robust—even as ecosystems evolve and new failure modes emerge.
Reliable resources & further reading
RFC 7515: JSON Web Signature (JWS). (Rédacteur du RFC)
RFC 7519: JSON Web Token (JWT). (IETF Datatracker)
PortSwigger: Algorithm confusion attacks. (PortSwigger)
OWASP WSTG: Testing JSON Web Tokens. (Fondation OWASP)
OWASP Cheat Sheet: JSON Web Token for Java. (Série d'aide-mémoire de l'OWASP)
Neil Madden: Psychic Signatures in Java. (Neil Madden)
JFrog analysis of CVE-2022-21449. (JFrog)
Cryptomathic explanation of CVE-2022-21449. (Cryptomathic)
