• Version : 1.0.0
• Serveurs : https://login.xsolla.com/api
• Protocoles : https
• Accepte : application/json
• Réponds avec : application/json
• Nous contacter par e-mail.
• URL de contact : https://xsolla.com/

Cette section décrit les appels API pour interagir avec Login. Configurez votre projet de connexion dans le Compte éditeur avant d'envoyer des requêtes.

The full list of IP addresses that login.xsolla.com may use:

• 34.94.0.85
• 34.94.14.95
• 34.94.25.33
• 34.94.115.185
• 34.94.154.26
• 34.94.173.132
• 34.102.48.30
• 35.235.99.248
• 35.236.32.131
• 35.236.35.100
• 35.236.117.164

Vous pouvez télécharger la définition de l'API dans deux formats :

• YAML
• JSON

Vous avez accès aux types de projets de connexion suivants dans le Compte éditeur :

• Projet de connexion standard
• Projet de connexion fantôme

Pour plus d'informations, voir la fonctionnalité Compte multiplateforme.

Il s'agit des restrictions appliquées par l'API Xsolla à la fréquence d'accès par un utilisateur au cours d'une période définie.

Il s'agit d'un projet de connexion utilisé pour stocker les comptes principaux.

Il s'agit d'un projet de connexion utilisé pour stocker les comptes de plateformes.

Il s'agit d'un type de compte créé dans un projet de connexion standard et lié aux comptes des plateformes. Le compte principal est utilisé pour identifier le joueur sur différentes plateformes.

Il s'agit d'un type de compte créé dans un projet de connexion fantôme et associé à une plateforme de publication spécifique. Le compte de plateforme ne peut pas être lié à un autre compte de plateforme. De même, vous ne pouvez pas dissocier les comptes d'un compte principal.

Il s'agit d'une plateforme de jeu utilisée pour la distribution des jeux (par exemple Steam, PlayStation, Xbox, etc.).

Login API prend en charge les types de jetons suivants :

• Jeton utilisateur. Il est utilisé pour envoyer des requêtes aux ressources utilisateur suivantes :
  • profil
  • amis
  • attributs
• Jeton de serveur. Il est utilisé pour envoyer des requêtes aux ressources de l'application telles que les paramètres ou les données utilisateur. Les requêtes suivantes sont disponibles :
  • Créer des comptes de plateforme
  • Lire les données utilisateur
  • Lier des comptes
  • Lier des comptes utilisateur par external ID

Le schéma d'authentification permet de déterminer si un appel API est effectué côté client ou côté serveur :

• Client-side — are called without authentication or with the Authorization header: Bearer <user_JWT> header, where <user_JWT> — is the user token.
• Server-side API calls for implementing the user flow — are called with the header: X-SERVER-AUTHORIZATION: <server_JWT>, where <server_JWT> — is the server token.

Pour obtenir le jeton, envoyez l'une des requêtes suivantes :

• enregistrement utilisateur (JWT ou OAuth 2.0)
• authentification par nom d'utilisateur et mot de passe (JWT, OAuth 2.0, ou authentification JWT par nom d'utilisateur et mot de passe)
• authentification via les réseaux sociaux (JWT ou OAuth 2.0)
• authentification silencieuse (JWT ou OAuth 2.0)
• authentification par jeton d'accès à un réseau social
• authentification via une plateforme de publication

Après l'authentification JWT, l'utilisateur est redirigé vers l'URL de rappel avec le jeton inclus dans le paramètre de la requête : <Callback URL>?token=<User token (JWT)>.

Après l'authentification basée sur le protocole OAuth 2.0, envoyez la requête Générer un JWT au serveur Xsolla Login pour échanger le paramètre code reçu contre un jeton utilisateur (access_token).

Pour obtenir un jeton de serveur :

1. Configurez le client OAuth 2.0 du serveur.
2. Générez le JWT du serveur.

Configurer le client OAuth 2.0 du serveur

1. Ouvrez votre projet dans le Compte éditeur et accédez à la section Login.
2. Dans le panneau d'un projet de connexion, cliquez sur Configure.
3. Accédez au bloc Security et sélectionnez la section OAuth 2.0.
4. Cliquez sur Add OAuth 2.0 Client.
5. Cochez la case Server (server-to-server connection).
6. Spécifiez la durée de vie Token lifetime.
7. Cliquez sur Connect.
8. Copiez et enregistrez l'ID client et la clé secrète.

Générer le JWT du serveur

Côté client de votre application, implémentez une méthode pour obtenir le JWT du serveur en utilisant l'appel Générer une API JWT. La requête doit contenir les paramètres suivants :

• grant_type est le type de JWT obtenu, passez la valeur client_credentials.
• client_secret est la clé secrète obtenue lors de la configuration du client OAuth 2.0 du serveur.
• client_id est l'ID client obtenu lors de la configuration du client OAuth 2.0 du serveur.

Pour éviter de surcharger le système Xsolla et prévenir les pics soudains de trafic entrant, Xsolla limite le nombre de requêtes reçues par l'API Xsolla au cours d'une période donnée. Si la limite est dépassée, l'API Xsolla renvoie une réponse HTTP avec le code d'état 429.

Rate limits vary by method, IP-address, authentication scheme, and other factors.

Rate limits for server-side methods are applied to methods with server-side authentication — methods that are called with the X-SERVER-AUTHORIZATION: <server_JWT> header, where <server_JWT> is the server token.

Rate limits for client-side methods are applied to methods without authentication or with client-side authentication — methods that are called with the Authorization: Bearer <user_JWT> header, where <user_JWT> is the user token.

Example of a method with server-side authentication: Example of a method with client-side authentication:

Les limites de fréquence pour les méthodes côté client restent inchangées et sont essentielles pour prévenir les attaques par force brute. En revanche, la fréquence maximale des requêtes pour les méthodes côté serveur est plus élevée que celle des méthodes côté client. Pour des recommandations sur la gestion des limites de fréquence, consultez la documentation .

Chaque jeton est au format JWT et contient une information précise dans une charge utile.

Le JWT utilisateur est un jeton obtenu à la suite d'une authentification ou d'un enregistrement. Il contient des informations sur l'utilisateur et des données sur l'appel d'authentification

L'obtention d'un jeton utilisateur via le protocole OAuth 2.0 nécessite un client OAuth 2.0. Le jeton utilisateur est passé dans l'en-tête Authorization: Bearer <JWT>.

Un jeton contient les revendications principales après l'authentification ou la confirmation de l'adresse e-mail. La présence de ces revendications ne dépend pas de la base de données utilisateur ni de l'appel d'authentification.

Revendications contenues dans le jeton après l'authentification si vous utilisez le stockage PlayFab.

Revendications contenues dans le jeton après l'authentification si vous utilisez un stockage personnalisé.

Revendications contenues dans le jeton après l'authentification via un réseau social. La présence de ces revendications ne dépend pas de la base de données des utilisateurs.

Revendications contenues dans le jeton après l'authentification OAuth 2.0.

Revendication contenue dans le jeton après l'authentification par numéro de téléphone.

Le jeton du serveur est passé dans l'en-tête X-SERVER-AUTHORIZATION.

La charge utile du jeton contient des informations sur les ressources dont le client OAuth 2.0 est propriétaire. Le jeton a accès aux appels avec authentification côté serveur pour ces ressources.

To validate the JWT, use the following Login API calls:

• User JWT validate — for a user token.
  • Server JWT validate — for a server token.

En cas d'erreur, le serveur Xsolla Login renvoie un objet JSON contenant les champs suivants :

{
  "error": {
    "code": "000-000",
    "description": "description"
  }
}