Variantes de base64 : alphabets standard et URL-safe, règles de padding et tolérance des décodeurs

Ce que c'est

Variante	Caractères 62/63 de l'alphabet	Padding	Retour à la ligne
Base64 standard (RFC 4648 §4)	+ /	obligatoire, sauf si la spécification qui y fait référence en dispose autrement — "MUST include appropriate pad characters"	interdit, sauf si la spécification qui y fait référence l'exige
URL-safe / base64url (RFC 4648 §5)	- _	même règle que pour le standard, sauf dérogation ; la RFC note que le padding peut être omis lorsque la longueur est connue	interdit, sauf si la spécification qui y fait référence l'exige
JWT / JWS BASE64URL (RFC 7515)	- _	explicitement omis — "with all trailing '=' characters omitted"	aucun autorisé — "without the inclusion of any line breaks"
MIME (RFC 2045)	+ /	obligatoire	obligatoire — 76 caractères au plus par ligne ; les décodeurs doivent ignorer les caractères hors de l'alphabet

Pourquoi c'est important

La RFC 4648 définit deux alphabets qui ne diffèrent que par deux caractères, et précise que le padding est obligatoire "unless the specification referring to this document explicitly states otherwise" (sauf mention contraire explicite de la spécification qui y fait référence). Les JWT constituent précisément une telle dérogation : la RFC 7515 supprime entièrement les = finaux et interdit les sauts de ligne, si bien qu'un segment de JWT complété par des = ou réparti sur plusieurs lignes est une entrée invalide pour un décodeur strict. MIME exige l'inverse : des lignes de 76 caractères au plus. La commande base64 de GNU coupe d'ailleurs sa sortie à cette largeur par défaut ; il faut donc lui passer explicitement -w0 pour obtenir une seule ligne continue (-w est une option de GNU coreutils ; le base64 de macOS ne coupe pas les lignes par défaut et utilise -b pour en demander). Les décodeurs divergent ensuite sur leur degré de tolérance. base64.b64decode en Python supprime les caractères hors de l'alphabet avant de vérifier le padding, sauf si l'on passe validate=True : une chaîne base64url qui lui est fournie perd ainsi ses - et _, puis soit produit des octets erronés, soit échoue sur le padding, sans jamais signaler les caractères fautifs. Il lève en outre Incorrect padding sur une entrée sans padding, ce que fait justement base64.urlsafe_b64decode avec un segment de JWT. Dans un navigateur, atob() lève une InvalidCharacterError sur -, _ ou tout autre caractère extérieur à l'alphabet standard, mais accepte l'absence de padding et ignore les caractères d'espacement ASCII. En Go, encoding/base64 maintient StdEncoding et URLEncoding comme des codecs distincts et non interchangeables, avec RawStdEncoding/RawURLEncoding comme formes explicites sans padding.

Comment l'appliquer

• Choisir l'alphabet selon le contexte : les URL, noms de fichiers et JWT nécessitent -/_ ; partout ailleurs, +// est la valeur par défaut.
• Retirer ou ajouter le padding en connaissance de cause : les JWT ne doivent pas en avoir ; la plupart des autres consommateurs l'attendent, sauf indication contraire dans leur documentation.
• Utiliser base64 -w0 chaque fois que la sortie d'un script doit tenir sur une seule ligne.
• Ne pas compter sur la tolérance par défaut de base64.b64decode ; passer validate=True lorsque les entrées malformées doivent être rejetées d'emblée.
• Avant de décoder en Python une valeur base64url sans padding, lui ajouter '=' * (-len(s) % 4) ; en Go, utiliser RawURLEncoding.

Pièges

• Fournir une chaîne avec padding et alphabet +// à un décodeur qui attend du base64url.
• Supposer que tous les décodeurs ignorent les caractères parasites comme le fait Python par défaut — atob() lève une exception à la place.
• Supposer que -w0 est portable : c'est une option de GNU coreutils, et le base64 de macOS utilise -b à la place.
• Oublier que -w0 est nécessaire pour éviter les sauts de ligne dans la sortie de base64 au sein d'un script.