Passer au contenu principal
Cette rubrique fournit un exemple de jeton XSTS issu de l’exemple client SimpleHttp, tel qu’il est traité par l’exemple Game Service. Ce jeton a été généré pour la partie de confiance et les paramètres suivants dans Partner Center :

Exemple de jeton

Découpage et traitement du jeton externe

Les différentes sections du jeton peuvent être découpées comme suit.

En-tête du jeton externe

Ainsi, par exemple, le composant d’en-tête est :
Vous pouvez saisir l’en-tête dans l’outil JSON Web Token (JWT) disponible à l’adresse https://jwt.io pour afficher le contenu suivant de l’en-tête une fois décodé.
Cela montre qu’il s’agit d’un JWT et que le certificat utilisé pour chiffrer la clé de chiffrement du contenu a pour empreinte 0004A3A12C1D5E59307A308D6D02E83978E2A9AE, que vous pouvez obtenir en décodant la valeur x5t avec Base64URL. AASjoSwdXlkwejCNbQLoOXjiqa4 -> décodage Base64Url en tableau d’octets -> [ 00-04-A3-A1-2C-1D-5E-59-30-7A-30-8D-6D-02-E8-39-78-E2-A9-AE ] -> Conversion en chaîne et suppression des caractères '-'

Déchiffrement de la clé de chiffrement du contenu (CEK)

À l’aide de la clé privée du certificat de la partie de confiance correspondant à l’empreinte, nous pouvons ensuite déchiffrer la clé de chiffrement du contenu (CEK) :
Le décodage base64Url renvoie le tableau d’octets suivant :
Nous pouvons ensuite déchiffrer la valeur décodée en Base64URL à l’aide de la clé privée RSA, ce qui renvoie la CEK entièrement décodée.

Obtention de la HMAC, de l’AES et du IV (vecteur d’initialisation) pour déchiffrer la charge utile

La CEK peut ensuite être divisée en hmacKey et aesKey. La clé HMAC correspond à la première moitié de la CEK, et la clé AES à la seconde moitié.
Le dernier élément dont nous avons besoin pour déchiffrer la charge utile du jeton externe est le vecteur d’initialisation. Le IV peut simplement être décodé en base64 à partir de la troisième section du jeton externe.

Déchiffrement de la charge utile

Grâce aux clés ci-dessus, nous pouvons maintenant déchiffrer la charge utile du jeton externe comme suit. Pour le code qui effectue ce déchiffrement, consultez les API DecryptAsync et Decrypt dans le fichier XstsUtilities.cs de l’exemple Game Service.
La décompression de ce tableau d’octets nous donne le jeton JWT interne. Pour plus d’informations, consultez DecompressAsync dans le fichier XstsUtilities.cs de l’exemple Game Service.

Traitement du jeton interne déchiffré

Après la décompression du tableau d’octets déchiffré de la charge utile du jeton externe, nous disposons d’un JSON Web Token (JWT) standard qui contient les revendications et les informations relatives à l’utilisateur, au titre et à l’appareil, telles que définies dans la partie de confiance.
L’outil de décodage JWT disponible à l’adresse https://jwt.io nous permet de voir ces revendications.
Pour plus d’informations sur les revendications qui peuvent être incluses dans la configuration de votre partie de confiance, consultez Revendications des jetons de sécurité des services XBOX.

Validation du jeton interne

Pour valider le contenu du jeton interne, votre service doit valider la signature du JWT conformément à la norme définie dans JWT RFC 7516. Cet exemple de jeton est configuré pour la validation de signature JKU dans Partner Center ; l’en-tête du jeton interne nous fournit donc les éléments suivants :
La valeur kid identifie la clé de signature XBOX Live spécifique utilisée pour générer la signature. La valeur jku pointe vers une URL à partir de laquelle la clé publique peut être téléchargée et utilisée pour valider la signature. Si le nom de domaine du jku n’est pas « xsts-keys.auth.xboxlive.com », le jeton ne doit pas être considéré comme fiable. Il est recommandé de mettre la clé en cache à l’exécution, car les clés de signature changent fréquemment. Cela permet également à votre service d’être résilient et de gérer l’obtention de nouvelles clés lorsqu’elles sont mises à jour à la volée, sans interruption de service ni maintenance. Si vous utilisez une solution JWT open source existante, la validation de la signature est effectuée automatiquement lorsque vous transmettez la clé publique JWK à l’API de décodage JWK. Après avoir validé la signature, votre service peut avoir l’assurance que le certificat et les données qu’il contient sont authentiques. Pour plus d’informations sur la validation du jeton interne, aussi bien pour la JWK de signature XBOX Live que pour le certificat de signature XBOX Live, consultez En-tête du jeton interne et validation de la signature

Identification du bon utilisateur dans le jeton

Les jetons contiennent les identités de tous les utilisateurs XBOX Live activement connectés au moment de la création du jeton sur le client. Votre service doit donc utiliser la valeur du hachage de l’utilisateur figurant dans l’en-tête d’autorisation HTTP et rechercher la valeur ush correspondante parmi les identités utilisateur. Pour cet exemple de jeton, l’en-tête Authorization comportait le hachage d’utilisateur 18026470712427541036. Nous pouvons ainsi constater que les revendications sont présentes pour ce hachage d’utilisateur, correspondant au gamertag 2 Dev 079574836. Bien que ce jeton ne contienne qu’une seule identité utilisateur dans ses revendications, nous devons tout de même vérifier qu’elle correspond au hachage d’utilisateur de l’en-tête.

Voir aussi

Revendications des jetons de sécurité des services XBOX Exemple de jeton de sécurité XBOX Live Authentification des services XBOX pour les services de titre
Dernière modification le 8 octobre 2026