Passer au contenu principal

Secrets partagés de joueur

Les secrets partagés de joueur constituent un nouveau type de pseudo-clé secrète, partagée entre les clients de jeu. À l’aide d’une API, elle peut être échangée contre la clé RSA publique du titre et peut être utilisée pour effectuer l’inscription de comptes. Les titres peuvent avoir plusieurs clés partagées de joueur, et peuvent les configurer et les révoquer à volonté, via les appels d’API Admin Create, Update, Delete, List. Les secrets partagés de joueur doivent être intégrés dans les clients respectifs, car il n’existe aucune API client permettant de les récupérer, qu’elle soit authentifiée ou non.

Clé publique du titre

Le secret partagé de joueur est ensuite envoyé à GetTitlePublicKey. Si la clé est valide, l’API renvoie un tableau d’octets de blob CSP RSA encodé en Base 64, capable de chiffrer 237 octets de données. Toutes les API qui permettent de créer des comptes acceptent désormais la publication d’une demande d’inscription sous forme de charge utile chiffrée dans le champ EncryptedRequest.
Les champs standard TitleId, InfoRequestParameters et CreateAccount ne doivent pas être inclus dans la charge utile chiffrée.

Utilisation de la clé publique du titre pour l’inscription

Voici un exemple de code permettant d’inscrire un joueur à l’aide de LoginWithCustomID et de la clé publique du titre.

Secret du joueur

Le nouveau système d’inscription comprend un nouveau champ appelé PlayerSecret. S’il est défini, il vous permet de signer les en-têtes de requête, qui sont validés par le serveur lors des appels d’API à tous les services, y compris les demandes de connexion. Le secret du joueur ne peut être défini qu’une seule fois par utilisateur et par titre. Un utilisateur possédant plusieurs titres dans le même studio doit définir le secret du joueur pour chacun d’eux. Si le secret du joueur n’a pas déjà été défini lors de l’inscription, il est possible de le définir en appelant SetPlayerSecret. Il existe des API admin et serveur qui permettent de définir le secret du joueur sur une nouvelle valeur, même s’il a déjà été défini.
Une fois défini, le secret du joueur doit être stocké de manière sécurisée sur l’appareil, car il n’est pas récupérable en cas de perte, et il n’existe aucune API permettant de le récupérer.

Utilisation du secret du joueur pour signer les requêtes d’API

L’exemple de code suivant construit un en-tête de signature pouvant être utilisé pour signer les requêtes d’API. Le format de l’en-tête de signature est présenté ci-dessous. jsonRequestModel.utcTimeStampInISO.playerSecret

Utilisation de l’application d’une stratégie

Les stratégies d’API peuvent désormais être utilisées pour imposer ces scénarios.
  • Une requête client est une charge utile chiffrée.
  • Une requête client contient des en-têtes signés.
Même sans utiliser l’application de stratégie, si une charge utile chiffrée est envoyée (ou si les en-têtes sont envoyés), ils seront validés. S’ils ne sont pas correctement formés, une erreur se produit. Pour créer une stratégie exigeant des en-têtes sur une API spécifique, utilisez une instruction Deny. Cela crée une stratégie exigeant des en-têtes sur tous les appels que vous pouvez effectuer et qui ne sont pas autorisés par l’instruction Allow. Les instructions de stratégie possèdent une propriété appelée ApiConditions. ApiConditions contient une propriété appelée HasSignatureOrEncryption, qui est une énumération avec trois valeurs possibles :
  • Any
  • True
  • False
La valeur par défaut (si elle n’est pas définie par la stratégie) est Any.
L’exemple de stratégie suivant autorise tous les appels d’API (à l’exception des appels non chiffrés ou sans en-têtes) vers LoginWithCustomID.
L’instruction Deny ci-dessus contient HasSignatureOrEncryption: False. Cela signifie que toutes les requêtes dépourvues de signature ou de chiffrement sont rejetées. En d’autres termes, toutes les requêtes qui possèdent des en-têtes de signature ou un chiffrement sont autorisées en vertu de Allow the rest policy.
Dernière modification le 6 octobre 2026