• Version: 1.0.0
• Server: https://login.xsolla.com/api
• Protokolle: https
• Akzeptiert: application/json
• Antwortet mit: application/json
• Kontaktieren Sie uns per E-Mail
• Kontakt-URL: https://xsolla.com/

Dieser Abschnitt beschreibt API-Aufrufe für die Arbeit mit Login. Konfigurieren Sie Ihr Login-Projekt im Kundenportal, bevor Sie Anfragen senden.

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

Die API-Definition steht in zwei Formaten zum Download bereit:

• YAML
• JSON

Im Kundenportal haben Sie Zugriff auf die folgenden Login-Projekttypen:

• Standard-Login-Projekt
• Schatten-Login-Projekt

Weitere Informationen dazu finden Sie unter Plattformübergreifendes Konto.

Are the restrictions applied by Xsolla API on the frequency of access by a user within a defined timeframe.

Ist ein Login-Projekt, das zum Speichern von Hauptkonten verwendet wird.

Ist ein Login-Projekt, das zum Speichern von Plattformkonten verwendet wird.

Ist ein in einem Standard-Login-Projekt erstellter Kontotyp und wird mit Plattformkonten verknüpft. Das Hauptkonto dient dazu, Spieler auf verschiedenen Plattformen zu identifizieren.

Ist ein in einem Schatten-Login-Projekt erstellter Kontotyp und wird mit einer bestimmten Publishing-Plattform verknüpft. Das Plattformkonto lässt sich mit keinem weiteren Plattformkonto verknüpfen. Zudem können Sie die Verknüpfung zwischen einem solchen Konto und einem Hauptkonto nicht aufheben.

Ist eine Plattform zur Distribution von Spielen (z. B. Steam, PlayStation, Xbox usw.).

Die Login API unterstützt die folgenden Tokentypen:

• Benutzertoken. Damit werden Anfragen an die folgenden Benutzerressourcen gesendet:
  • Profil
  • Freunde
  • Attribute
• Servertoken. Damit werden Anfragen an Anwendungsressourcen (z. B. Einstellungen oder Benutzerdaten) gesendet. Folgende Anfragen stehen zur Verfügung:
  • Plattformkonten erstellen
  • Benutzerdaten abrufen
  • Konten verknüpfen
  • Benutzerkonten über externe ID verknüpfen

Ob ein API-Aufruf client- oder serverseitig erfolgt, können Sie anhand des Authentifizierungsschemas feststellen:

• 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.

Senden Sie eine der folgenden Anfragen, um den Token abzurufen:

• Benutzerregistrierung (JWT oder OAuth  2.0)
• Authentifizierung durch Benutzername und Passwort (JWT, OAuth  2.0, oder JWT-Authentifizierung durch Benutzername und Passwort)
• Authentifizierung über soziale Netzwerke (JWT oder OAuth  2.0)
• stille Authentifizierung (JWT oder OAuth  2.0)
• Authentifizierung über einen Social-Media- Zugriffstoken
• Authentifizierung über eine Publishing- Plattform

Nach der JWT-Authentifizierung wird der Benutzer mithilfe eines Tokens in einem Abfrageparameter zur Rückruf-URL weitergeleitet: <Callback URL>?token=<User token (JWT)>.

After OAuth 2.0 protocol-based authentication, send the Generate JWT POST request to the Xsolla Login server to exchange the received code parameter for a user token (access_token).

When the access token expires, the client sends Generate JWT POST request endpoint on the Xsolla Login server. The request body must include the following parameters:

• grant_type — JWT grant type, pass the refresh_token value.
• client_id — OAuth 2.0 client ID.
• refresh_token — refresh token received in response to the user authorization request.

So rufen Sie ein Servertoken ab:

1. Richten Sie den OAuth 2.0-Serverclient ein.
2. Generieren Sie den JWT.

OAuth 2.0-Serverclient einrichten

1. Öffnen Sie Ihr Projekt im Kundenportal, und wechseln Sie zum Abschnitt Login.
2. Klicken Sie beim gewünschten Login-Projekt auf Konfigurieren.
3. Scrollen Sie zum Block Sicherheit, und wählen Sie OAuth 2.0 aus.
4. Click Add OAuth 2.0 Client.
5. Aktivieren Sie das Kontrollkästchen Server (Server-zu-Server-Verbindung).
6. Legen Sie die Tokenlebensdauer fest.
7. Klicken Sie auf Verknüpfen.
8. Kopieren und speichern Sie die Client-ID und den geheimen Schlüssel.

Server-JWT generieren

Implementieren Sie im Backend Ihrer Anwendung eine Methode, um den Server-JWT mithilfe des API-Aufrufs JWT generieren abzurufen. Die Anfrage muss folgende Parameter enthalten:

• grant_type is the type of getting JWT, pass the client_credentials value.
• client_secret is the secret key that is received when you set up the server OAuth 2.0 client.
• client_id is the client ID received when you set up the server OAuth 2.0 client.

When the server token expires, generate a new token using the Generate JWT API call. The request body must include the following parameters:

• grant_type — JWT grant type, pass the client_credentials value.
• client_id — OAuth 2.0 client ID.
• client_secret — OAuth 2.0 client secret key.

To prevent Xsolla system overloads and protect against sudden spikes in incoming traffic, Xsolla limits the number of requests received by the Xsolla API within a specified period of time. If the limit is exceeded, the Xsolla API returns an HTTP response with the 429 status code.

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:

Rate limits for client-side methods do not change and are necessary to prevent brute-force attacks. The maximum request rate for server-side methods is higher than for client-side methods. You can refer to the recommendations on how to manage rate limits in the documentation.

Jeder Token hat ein JWT-Format und enthält eine bestimmte Information in einer Payload.

Ein Benutzer-JWT ist ein Token, der infolge einer Authentifizierung oder Registrierung empfangen wird. Eine Token-Payload enthält Informationen über den Benutzer und den Authentifizierungsaufruf.

Um einen Benutzertoken über das OAuth 2.0-Protokoll abzurufen, ist ein OAuth  2.0-Client erforderlich. Der Benutzertoken wird im Header Authorization: Bearer <JWT> übermittelt.

Nach der Authentifizierung oder Bestätigung der E-Mail-Adresse enthält ein Token die wichtigsten Claims. Ob diese Claims vorhanden sind, hängt nicht von der Nutzerdatenbank und dem Authentifizierungsaufruf ab.

Claims, die nach der Authentifizierung im Token enthalten sind, sofern Sie den PlayFab-Speicher verwenden.

Claims, die nach der Authentifizierung im Token enthalten sind, sofern Sie einen eigenen Speicher verwenden.

Claims, die nach der Authentifizierung über ein soziales Netzwerk im Token enthalten sind. Ob diese Claims vorhanden sind, hängt nicht von der Nutzerdatenbank ab.

Claims, die nach der OAuth 2.0-Authentifizierung im Token enthalten sind.

Claim, der nach der Authentifizierung über eine Telefonnummer im Token enthalten ist.

Der Servertoken wird im X-SERVER-AUTHORIZATION-Header übermittelt.

Die Token-Payload enthält Informationen über Ressourcen, die dem OAuth  2.0-Client gehören. Der Token kann auf diese Ressourcen durch Aufrufe mit serverbasierter Authentifizierung zugreifen.

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

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

Refer to the documentation for information about Xsolla Login API errors.