Skip to main content

Secretos compartidos de jugador

Los secretos compartidos de jugador son un nuevo tipo de clave pseudosecreta que se comparte entre los clientes del juego. Mediante una API, se puede intercambiar por la clave RSA pública del título y se puede usar para realizar el registro de cuentas. Los títulos pueden tener varias claves compartidas de jugador, y pueden configurarlas y revocarlas a voluntad mediante las llamadas a la API de administración Create, Update, Delete y List. Los secretos compartidos de jugador deben integrarse en los clientes respectivos, ya que no hay ninguna API de cliente para recuperarlos, ni autenticada ni de ningún otro tipo.

Clave pública del título

A continuación, el secreto compartido de jugador se envía a GetTitlePublicKey. Si la clave es válida, la API devuelve una matriz de bytes de blob CSP RSA codificada en Base 64 que puede cifrar 237 bytes de datos. Todas las API que permiten crear cuentas ahora aceptan la publicación de una solicitud de registro como carga cifrada en el campo EncryptedRequest.
Los campos estándar TitleId, InfoRequestParameters y CreateAccount no deben incluirse en la carga cifrada.

Uso de la clave pública del título para registrarse

Este es un ejemplo de código para registrar un jugador con LoginWithCustomID y la clave pública del título.

Secreto de jugador

Una parte del nuevo sistema de registro es un nuevo campo denominado PlayerSecret. Si se establece, le permite firmar los encabezados de las solicitudes, que el servidor valida durante las llamadas a la API de todos los servicios, incluidas las solicitudes de inicio de sesión. El secreto de jugador solo se puede establecer una vez por usuario y por título. Un usuario con varios títulos en el mismo estudio debe establecer el secreto de jugador para cada uno de ellos. Si el secreto de jugador aún no se ha establecido durante el registro, es posible establecerlo llamando a SetPlayerSecret. Hay API de administración y de servidor que permiten establecer el secreto de jugador en un nuevo valor incluso si ya se había establecido anteriormente.
Una vez establecido, el secreto de jugador debe almacenarse de forma segura en el dispositivo, ya que no se puede recuperar si se pierde y no existe ninguna API para recuperarlo.

Uso del secreto de jugador para firmar solicitudes de API

En el siguiente ejemplo de código se construye un encabezado de firma que se puede usar para firmar solicitudes de API. El formato del encabezado de firma se muestra a continuación. jsonRequestModel.utcTimeStampInISO.playerSecret

Uso de una aplicación de directivas

Las directivas de API ahora se pueden usar para aplicar estos escenarios.
  • Una solicitud de cliente es una carga cifrada.
  • Una solicitud de cliente contiene encabezados firmados.
Incluso sin usar la aplicación de directivas, si se envía una carga cifrada (o se envían los encabezados), se validarán. Si no tienen el formato correcto, se produce un error. Para crear una directiva que exija encabezados en una API específica, use una instrucción Deny. Esto crea una directiva que exige encabezados en todas las llamadas que pueda realizar y que no estén permitidas por la instrucción Allow. Las instrucciones de directiva tienen una propiedad denominada ApiConditions. ApiConditions contiene una propiedad denominada HasSignatureOrEncryption, que es una enumeración con tres valores posibles:
  • Any
  • True
  • False
El valor predeterminado (si no lo establece la directiva) es Any.
La siguiente directiva de ejemplo permite todas las llamadas a la API (excepto las llamadas sin cifrar o sin encabezados) a LoginWithCustomID.
La instrucción Deny anterior contiene HasSignatureOrEncryption: False. Esto significa que se rechazan todas las solicitudes que no tienen firma ni cifrado. En otras palabras, todas las solicitudes que tienen encabezados de firma o cifrado se permiten en función de la directiva Allow the rest policy.
Última modificación el 28 de agosto de 2026