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

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

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

Senden Sie nach der auf dem OAuth 2.0-Protokoll basierenden Authentifizierung die Anfrage JWT generieren an den Xsolla-Login-Server, um den empfangenen code-Parameter gegen einen Benutzertoken (access_token) zu tauschen.

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.

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, authorization type, and other factors.

Rate limits for server-side methods are applied to methods with server-side authorization — 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 authorization or with client-side authorization — 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 authorization: Example of a method with client-side authorization:

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.

Nach erfolgreicher Authentifizierung wird für jeden Benutzer ein JWT generiert. Der generierte JWT wird mit einem geheimen Schlüssel signiert. Um sicherzustellen, dass ein JWT relevant ist und dem Benutzer Ihres Login-Projekts gehört, sollten Sie seinen Wert validieren.

So validieren Sie einen JWT:

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 auf der Navigationsseite zum Block Sicherheit, und wählen Sie JWT-Signatur aus.
4. Wählen Sie die Verschlüsselungsmethode aus, und kopieren Sie den Wert des Feldes Geheimer Schlüssel bzw. Neuer öffentlicher JSON-Webschlüssel, je nach ausgewählter Methode.
5. Wählen Sie die Bibliothek, und verknüpfen Sie diese serverseitig mit Ihrer Anwendung.
6. Übermitteln Sie den in Schritt 4 kopierten Wert an den Validierungsfunktionseintrag.

Bei Fehlermeldungen gibt der Xsolla-Login-Server ein JSON-Objekt mit den folgenden Feldern zurück:

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