Secrets partagés par les joueurs
Les secrets partagés par les joueurs constituent un nouveau type de pseudo-clé secrète, partagée entre les clients de jeu. À l’aide d’une API, ils peuvent être échangés contre la clé RSA publique du titre, puis utilisés pour effectuer l’inscription de comptes. Les titres peuvent avoir plusieurs clés partagées par les joueurs, et peuvent les configurer et les révoquer à volonté au moyen des appels de l’API Admin Create, Update, Delete, List. Les secrets partagés par les joueurs doivent être intégrés dans les clients respectifs, car il n’existe aucune API client pour les récupérer, avec ou sans authentification.Clé publique du titre
Le secret partagé par les joueurs est ensuite envoyé à GetTitlePublicKey. Si la clé est valide, l’API renvoie un tableau d’octets de blob CSP RSA encodé en Base 64 qui peut chiffrer 237 octets de données. Toutes les API qui permettent de créer des comptes acceptent maintenant la publication d’une demande d’inscription sous forme de charge utile chiffrée dans le champEncryptedRequest.
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 deLoginWithCustomID 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 demande, 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 ayant 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. Des API d’administration et de serveur permettent de définir le secret du joueur à 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 façon sécuritaire sur l’appareil, car il n’est pas récupérable en cas de perte, et il n’existe aucune API pour le récupérer.
Utilisation du secret du joueur pour signer les demandes d’API
L’exemple de code suivant construit un en-tête de signature qui peut être utilisé pour signer les demandes 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 maintenant être utilisées pour imposer ces scénarios.- Une demande client est une charge utile chiffrée.
- Une demande client contient des en-têtes signés.
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 permis par l’instruction Allow.
Les instructions de stratégie ont une propriété appelée ApiConditions. ApiConditions contient une propriété appelée HasSignatureOrEncryption, qui est une énumération comportant trois valeurs possibles :
AnyTrueFalse
La valeur par défaut (si elle n’est pas définie par la stratégie) est
Any.LoginWithCustomID.
Deny ci-dessus contient HasSignatureOrEncryption: False. Cela signifie que toutes les demandes qui n’ont pas de signature ni de chiffrement sont rejetées. Autrement dit, toutes les demandes qui ont des en-têtes de signature ou un chiffrement sont autorisées en fonction de Allow the rest policy.