トークンの例
外側トークンの分割と処理
トークンのさまざまなセクションは次のように分割できます。外側トークンのヘッダー
たとえば、ヘッダー コンポーネントは以下のとおりです:0004A3A12C1D5E59307A308D6D02E83978E2A9AE であることを示しています。この値は Base64URL を使用して x5t 値をデコードすることで取得できます。
AASjoSwdXlkwejCNbQLoOXjiqa4 -> Base64Url でバイト配列にデコード -> [ 00-04-A3-A1-2C-1D-5E-59-30-7A-30-8D-6D-02-E8-39-78-E2-A9-AE ]
-> 文字列に変換し、'-' 文字を除去
コンテンツ暗号化キー (CEK) の復号
サムネイルに一致する証明書利用者証明書の秘密鍵を使用して、コンテンツ暗号化キー (CEK) を復号できます:HMAC、AES、IV (初期化ベクトル) を取得してペイロードを復号する
CEK はhmacKey と aesKey に分割できます。
HMAC キーは CEK の前半、AES キーは後半です。
ペイロードの復号
上記のキーを使用して、外側トークンのペイロードを次のように復号できます。 この復号を行うコードについては、Game Service サンプル の XstsUtilities.cs 内のDecryptAsync および Decrypt API を参照してください。
DecompressAsync を参照してください。
復号された内側トークンの処理
外側トークン ペイロードの復号バイト配列を解凍した後、証明書利用者で定義されたユーザー、タイトル、およびデバイスに関するクレームを含む標準の JSON Web Token (JWT) が得られます。内側トークンの検証
内側トークンの内容を検証するには、サービスは JWT RFC 7516 で定義された標準に従って JWT の署名を検証する必要があります。 このサンプル トークンは Partner Center で JKU 署名検証用に構成されているため、内側トークンのヘッダーは以下のようになります:kid の値は、署名の生成に使用された特定の XBOX Live 署名キーを識別します。
jku の値は、公開鍵をダウンロードして署名の検証に使用できる URL を指しています。
jku のドメイン名が “xsts-keys.auth.xboxlive.com” でない場合、そのトークンは信頼すべきではありません。
署名キーは頻繁に変更されるため、実行時にキーをキャッシュすることを推奨します。
これにより、サービスは回復力を持ち、ダウンタイムや保守なしで新しいキーが更新されたときに動的に取得できるようになります。
既存の JWT オープンソース ソリューションを使用している場合、JKW 公開鍵を JWK デコード API に渡すと、署名の検証は自動的に行われます。
署名を検証した後、サービスは証明書とその内部のデータが本物であると信頼できます。
XBOX Live 署名 JWK と XBOX Live 署名証明書の両方に対する内側トークン検証の詳細については、内側トークンのヘッダーと署名の検証 を参照してください。
トークン内で正しいユーザーを識別する
トークンには、クライアント上でトークンが作成された時点でアクティブにサインインしていたすべての XBOX Live ユーザーのユーザー ID が含まれています。 そのため、サービスは HTTP 認可ヘッダーからのユーザー ハッシュ値を使用し、ユーザー ID 内で一致するush 値を見つける必要があります。
このサンプル トークンでは、Authorization ヘッダーのユーザー ハッシュは 18026470712427541036 でした。
これにより、ゲーマータグ 2 Dev 079574836 のこのユーザー ハッシュに対するクレームがあることが分かります。
このトークンにはトークン クレーム内にユーザー ID が 1 つしかありませんが、それでもヘッダーからのユーザー ハッシュと一致するかを検証すべきです。
