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 :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) :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 enhmacKey et aesKey.
La clé HMAC correspond à la première moitié de la CEK, et la clé AES à la seconde moitié.
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 APIDecryptAsync et Decrypt dans le fichier XstsUtilities.cs de l’exemple Game Service.
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.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 :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 valeurush 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.
