Token de exemplo
Dividindo e tratando o token externo
As várias seções do token podem ser divididas da seguinte forma.Cabeçalho do token externo
Assim, por exemplo, o componente de cabeçalho é:0004A3A12C1D5E59307A308D6D02E83978E2A9AE, que você pode obter usando Base64URL para decodificar o valor x5t.
AASjoSwdXlkwejCNbQLoOXjiqa4 -> decodificar Base64Url em matriz de bytes -> [ 00-04-A3-A1-2C-1D-5E-59-30-7A-30-8D-6D-02-E8-39-78-E2-A9-AE ]
-> Converter em cadeia de caracteres e remover os caracteres '-'
Descriptografando a chave de criptografia de conteúdo (CEK)
Usando a chave privada do certificado da terceira parte confiável que corresponde à impressão digital, podemos então descriptografar a Content Encryption Key (CEK):Obtendo o HMAC, o AES e o IV (vetor de inicialização) para descriptografar o conteúdo
A CEK pode então ser dividida emhmacKey e aesKey.
A chave HMAC é a primeira metade da CEK, e a chave AES é a segunda metade.
Descriptografando o conteúdo
Com as chaves acima, agora podemos descriptografar o conteúdo do token externo, obtendo o seguinte. Para ver o código que faz essa descriptografia, consulte as APIsDecryptAsync e Decrypt em XstsUtilities.cs do exemplo Game Service.
DecompressAsync em XstsUtilities.cs do exemplo Game Service.
Tratando o token interno descriptografado
Depois de descompactar a matriz de bytes descriptografada do conteúdo do token externo, agora temos um JSON Web Token (JWT) padrão que abriga as declarações e as informações do usuário, do título e do dispositivo, conforme definido na terceira parte confiável.Validando o token interno
Para validar o conteúdo do token interno, seu serviço deve validar a assinatura do JWT seguindo o padrão definido no JWT RFC 7516. Este token de exemplo está configurado para validação de assinatura JKU no Partner Center; portanto, o cabeçalho do token interno nos fornece o seguinte:kid identifica a chave de assinatura específica do XBOX Live usada para gerar a assinatura.
O valor jku aponta para uma URL em que a chave pública pode ser baixada e usada para validar a assinatura.
Se o nome de domínio do jku não for “xsts-keys.auth.xboxlive.com”, o token não deverá ser considerado confiável.
É recomendável armazenar a chave em cache em tempo de execução, pois as chaves de assinatura mudam com frequência.
Isso também permite que seu serviço seja resiliente e capaz de obter novas chaves quando elas forem atualizadas dinamicamente, sem tempo de inatividade ou manutenção.
Se você estiver usando uma solução JWT de código aberto existente, a validação da assinatura será feita automaticamente quando você passar a chave pública JKW para a API de decodificação de JWK.
Depois de validar a assinatura, seu serviço pode confiar que o certificado e os dados nele contidos são autênticos.
Para obter mais informações sobre a validação do token interno tanto para a JWK de assinatura do XBOX Live quanto para o certificado de assinatura do XBOX Live, consulte Validação do cabeçalho e da assinatura do token interno
Identificando o usuário correto no token
Os tokens terão identidades de usuário para todos os usuários do XBOX Live que estavam ativamente conectados no momento em que o token foi criado no cliente. Portanto, seu serviço precisa usar o valor de hash do usuário do cabeçalho de autorização HTTP e encontrar o valorush correspondente nas identidades de usuário.
Para este token de exemplo, o cabeçalho Authorization tinha um hash de usuário 18026470712427541036.
A partir disso, podemos ver que as declarações estão presentes para esse hash de usuário, cuja gamertag é 2 Dev 079574836.
Embora este token tenha apenas uma identidade de usuário nas declarações, ainda devemos validar se ela corresponde ao hash de usuário do cabeçalho.
