App-only-Authentifizierung und OAuth 2.0 Bearer Token

​

App only Authentifizierung und OAuth 2.0 Bearer Token

X bietet Anwendungen die Möglichkeit, authentifizierte Anfragen im Namen der Anwendung selbst zu stellen, statt im Namen eines bestimmten Nutzers. Die Implementierung von X basiert auf dem Client Credentials Grant-Flow der OAuth 2-Spezifikation.

Die ausschließlich anwendungsbezogene Authentifizierung enthält keinen Nutzerkontext und ist eine Form der Authentifizierung, bei der eine Anwendung API-Anfragen in eigenem Namen stellt. Diese Methode ist für Entwickler gedacht, die lediglich Lesezugriff auf öffentliche Informationen benötigen.

Sie können die ausschließlich anwendungsbezogene Authentifizierung mithilfe der Consumer-API-Keys Ihrer App durchführen oder indem Sie ein App only Access Token (Bearer Token) verwenden. Das bedeutet, dass die Anfragen, die Sie an die X API stellen können, keinen authentifizierten Nutzer erfordern dürfen.

Mit ausschließlich anwendungsbezogener Authentifizierung können Sie unter anderem Folgendes ausführen:

• Nutzer-Timelines abrufen
• Auf Freunde und Follower eines beliebigen Kontos zugreifen
• Auf List-Ressourcen zugreifen
• Tweets durchsuchen

Bitte beachten Sie, dass nur OAuth 1.0a oder der OAuth 2.0 Authorization Code Flow mit PKCE erforderlich ist, um Anfragen im Namen von Nutzern zu stellen. Die Seite API reference beschreibt die für die Nutzung einer API erforderliche Authentifizierungsmethode. Sie benötigen Nutzer-Authentifizierung und Nutzerkontext mit einem access token, um Folgendes durchzuführen:

• Tweets oder andere Ressourcen veröffentlichen
• Nach Nutzern suchen
• Beliebige Geo-endpoints verwenden
• Auf Direct Messages oder Kontozugangsdaten zugreifen
• E-Mail-Adressen von Nutzern abrufen

​

Authentifizierungsablauf

Um diese Methode zu verwenden, müssen Sie ein App only Access Token (auch als Bearer Token bezeichnet) verwenden. Sie können ein App only Access Token (Bearer Token) erzeugen, indem Sie Ihren Consumer Key und Ihr Consumer Secret über den POST oauth2/token-Endpoint übergeben.

Der anwendungsbasierte Authentifizierungsablauf umfasst folgende Schritte:

• Eine Anwendung codiert ihren Consumer Key und ihr Consumer Secret zu einem speziell codierten Satz von Anmeldedaten.
• Die Anwendung stellt eine Anfrage an den POST oauth2/token-Endpoint, um diese Anmeldedaten gegen ein App only Access Token einzutauschen.
• Beim Zugriff auf die REST API verwendet die Anwendung das App only Access Token zur Authentifizierung.

Da Anfragen nicht signiert werden müssen, ist dieser Ansatz deutlich einfacher als das Standardmodell OAuth 1.0a.

​

Über App-only-Authentifizierung

Tokens sind Passwörter

Beachten Sie, dass der Consumer Key & Secret und das App only Access Token (Bearer Token) selbst den Zugriff ermöglichen, im Namen einer Anwendung Anfragen zu stellen. Diese Werte sollten als ebenso sensibel wie Passwörter behandelt werden und dürfen nicht mit nicht vertrauenswürdigen Parteien geteilt oder an diese weitergegeben werden.

SSL erforderlich

Alle Anfragen (sowohl zum Erhalten als auch zur Verwendung der Tokens) müssen HTTPS-endpoints verwenden. Befolgen Sie die Best Practices in Connecting to X API using TLS — Peers sollten immer verifiziert werden.

Kein Benutzerkontext

Bei Anfragen mit App-only-Authentifizierung gibt es kein Konzept eines „aktuellen Benutzers“. Daher funktionieren endpoints wie POST statuses/update nicht mit App-only-Authentifizierung. Siehe using OAuth für weitere Informationen zum Stellen von Anfragen im Namen eines Benutzers.

Rate Limiting

Anwendungen haben zwei Arten von Rate-Limiting-Pools.

Anfragen im Namen von Nutzern mit access tokens, auch als Benutzerkontext bekannt, werden von einem anderen Rate-Limiting-Kontext abgezogen als der, der bei der App-only-Authentifizierung verwendet wird. Mit anderen Worten: Anfragen im Namen von Nutzern verbrauchen nicht die über App-only-Authentifizierung verfügbaren Rate Limits, und Anfragen über App-only-Authentifizierung verbrauchen nicht die Rate Limits, die bei benutzerbasierter Authentifizierung verwendet werden.

Lesen Sie mehr über API Rate Limiting und prüfen Sie die Limits.

​

Ausführung von App-only-Anfragen

Schritt 1: Consumer Key und Secret encodieren

So encodieren Sie den Consumer Key und das Consumer Secret einer Anwendung zu Anmeldedaten, um ein Bearer Token zu erhalten:

1. URL-encodieren Sie den Consumer Key und das Consumer Secret gemäß RFC 1738. Beachten Sie, dass dies zum Zeitpunkt der Erstellung dieses Textes den Consumer Key und das Secret zwar nicht verändert, dieser Schritt sollte jedoch dennoch durchgeführt werden, falls sich das Format dieser Werte künftig ändert.
2. Konkatenieren Sie den encodierten Consumer Key, ein Doppelpunktzeichen „:“, und das encodierte Consumer Secret zu einer einzelnen Zeichenkette.
3. Base64-encodieren Sie die Zeichenkette aus dem vorherigen Schritt.

Unten finden Sie Beispielwerte, die das Ergebnis dieses Verfahrens zeigen. Beachten Sie, dass das auf dieser Seite verwendete Consumer Secret nur zu Testzwecken dient und für echte Anfragen nicht funktioniert.

Consumer Key	xvz1evFS4wEEPTGEFPHBog
Consumer Secret	L8qq9PZyRg6ieKGEKhZolGC0vJWLw8iEJ88DRdyOg
RFC-1738-encodierter Consumer- Key (unverändert)	xvz1evFS4wEEPTGEFPHBog
RFC-1738-encodiertes Consumer- Secret (unverändert)	L8qq9PZyRg6ieKGEKhZolGC0vJWLw8iEJ88DRdyOg
Bearer-Token-Anmeldedaten	xvz1evFS4wEEPTGEFPHBog:L8qq9PZyRg6ieKGEKhZolGC0vJWLw8iEJ88DRdyOg
Base64-encodierte Bearer-Token-Anmeldedaten	:: eHZ6MWV2RlM0d0VFUFRHRUZQSEJvZzpMOHFxOVBaeVJnNmllS0dFS2hab2xHQzB2SldMdzhpRUo4OERSZHlPZw==

Schritt 2: App only Access Token (Bearer Token) abrufen

Der in Schritt 1 berechnete Wert muss gegen ein App only Access Token ausgetauscht werden, indem eine Anfrage an POST oauth2/token gestellt wird:

• Die Anfrage muss eine HTTP-POST-Anfrage sein.
• Die Anfrage muss einen Authorization-Header mit dem Wert Basic <base64 encoded value from step 1>. enthalten.
• Die Anfrage muss einen Content-Type-Header mit dem Wert application/x-www-form-urlencoded;charset=UTF-8. enthalten.
• Der Anfrage-Body muss grant_type=client_credentials enthalten.

Beispielanfrage (Authorization-Header wurde umbrochen):

POST /oauth2/token HTTP/1.1
Host: api.x.com
User-Agent: My X App v1.0.23
Authorization: Basic eHZ6MWV2RlM0d0VFUFRHRUZQSEJvZzpMOHFxOVBaeVJn
                     NmllS0dFK2hab2xHQzB2SldMdzhpRUo4OERSZHlPZw==
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Content-Length: 29
Accept-Encoding: gzip

grant\_type=client\_credentials

Wenn die Anfrage korrekt formatiert ist, antwortet der Server mit einer JSON-codierten Nutzlast:

Beispielantwort:

HTTP/1.1 200 OK
Status: 200 OK
Content-Type: application/json; charset=utf-8
...
Content-Encoding: gzip
Content-Length: 140

{"token\_type":"bearer","access\_token":"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%2FAAAAAAAAAAAAAAAAAAAA%3DAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"}

Anwendungen sollten prüfen, ob der dem Schlüssel token_type des zurückgegebenen Objekts zugeordnete Wert bearer ist. Der dem Schlüssel access_token zugeordnete Wert ist das App only Access Token (Bearer Token).

Beachten Sie, dass jeweils nur ein App only Access Token pro Anwendung gültig ist. Eine weitere Anfrage mit denselben Anmeldedaten an /oauth2/token gibt dasselbe Token zurück, bis es invalidiert wird.

Schritt 3: API-Anfragen mit dem App only Access Token (Bearer Token) authentifizieren

Das App only Access Token (Bearer Token) kann verwendet werden, um Anfragen an API-endpoints zu stellen, die App-only-Authentifizierung unterstützen. Um das App Access Token zu verwenden, erstellen Sie eine normale HTTPS-Anfrage und fügen Sie einen Authorization-Header mit dem Wert Bearer <base64 bearer token value from step 2>. Signing is not required. ein.

Beispielanfrage (Authorization-Header wurde umbrochen):

GET /1.1/statuses/user\_timeline.json?count=100&screen\_name=twitterapi HTTP/1.1
Host: api.x.com
User-Agent: My X App v1.0.23
Authorization: Bearer AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%2FAAAAAAAAAAAA
                      AAAAAAAA%3DAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Accept-Encoding: gzip

Ungültigmachen eines App only Access Token (Bearer Token)

Sollte ein App only Access Token kompromittiert sein oder aus irgendeinem Grund ungültig gemacht werden müssen, senden Sie eine Anfrage an POST oauth2/invalidate_token.

Beispielanfrage (Authorization-Header wurde umbrochen):

POST /oauth2/invalidate_token HTTP/1.1
Authorization: Basic eHZ6MWV2RlM0d0VFUFRHRUZQSEJvZzpMOHFxOVBaeVJn
                     NmllS0dFS2hab2xHQzB2SldMdzhpRUo4OERSZHlPZw==
User-Agent: Meine X App v1.0.23
Host: api.x.com
Accept: */*
Content-Length: 119
Content-Type: application/x-www-form-urlencoded

access_token=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%2FAAAAAAAAAAAAAAAAAAAA%3DAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Beispielantwort:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 127
...

{"access_token":"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%2FAAAAAAAAAAAAAAAAAAAA%3DAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"}

​

Häufige Fehlerfälle

Dieser Abschnitt beschreibt einige häufige Fehler bei der Aushandlung und Verwendung von Bearer Tokens. Beachten Sie, dass hier nicht alle möglichen Fehlerantworten abgedeckt sind – achten Sie auf nicht behandelte Fehlercodes und -antworten.

Ungültige Anfragen zum Abrufen oder Widerrufen eines App only Access Token

Versuche, Folgendes zu tun:

• Ein App only Access Token (Bearer Token) mit einer ungültigen Anfrage abzurufen (zum Beispiel durch Weglassen von grant_type=client_credentials).
• Ein App only Access Token (Bearer Token) mit falschen oder abgelaufenen App-Anmeldedaten abzurufen oder zu widerrufen.
• Ein falsches oder widerrufenes App only Access Token (Bearer Token) ungültig zu machen.
• Ein App only Access Token (Bearer Token) in kurzer Zeit zu häufig abzurufen.

führen zu:

HTTP/1.1 403 Forbidden
Content-Length: 105
Content-Type: application/json; charset=utf-8
...

{"errors":\[{"code":99,"label":"authenticity\_token\_error","message":"Ihre Anmeldedaten können nicht verifiziert werden"}\]}

​

API‑Anfrage enthält einen ungültigen App only Access Token (Bearer Token)

Die Verwendung eines falschen oder widerrufenen Access Token für API‑Anfragen führt zu:

HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
Content-Length: 61
...

{"errors":[{"message":"Ungültiges oder abgelaufenes Token","code":89}]}

​

App only Access Token (Bearer Token) auf endpoint verwendet, der keine App-only-Authentifizierung unterstützt

Das Anfordern eines endpoint, der einen Benutzerkontext erfordert (z. B. statuses/home_timeline), mit einem App only Access Token (Bearer Token) führt zu:

HTTP/1.1 403 Forbidden
Content-Type: application/json; charset=utf-8
Content-Length: 91
...

{"errors":\[{"message":"Ihre Anmeldedaten erlauben keinen Zugriff auf diese Ressource","code":220}\]}