OAuth Echo

​

OAuth Echo

OAuth Echo ist ein Verfahren, um die OAuth-Autorisierung bei der Interaktion mit einer API sicher an eine Drittpartei zu delegieren.

An dieser Interaktion sind vier Parteien beteiligt:

• der Nutzer, der X über eine bestimmte, autorisierte X-Anwendung verwendet
• der Consumer, also die X-Anwendung, die versucht, mit dem Drittanbieter-Mediendienst zu interagieren (z. B. der Foto-Sharing-Seite)
• der Delegator, also der Drittanbieter-Mediendienst
• der Service Provider, alias X selbst  

Im Kern bereiten Sie eine Anfrage für den Delegator vor, die dieser im Namen einer Anwendung und eines Nutzers an die X API sendet. Fügen Sie das, was sonst eine signierte OAuth-Anfrage wäre, in einen HTTP-Header ein, und bitten Sie den Delegator, diese Anfrage nach Abschluss des Zwischenschritts an X zu senden.

Hier ein Beispiel: Der Nutzer möchte ein Foto hochladen. Der Consumer ruft beim Delegator den Upload per POST auf. Der POST sollte das Bild enthalten, aber zusätzlich zwei Elemente als HTTP-Header:

• x-auth-service-provider — dies ist im Grunde der Bereich (Realm), an den die Identitätsdelegation gesendet werden soll — im Fall von X setzen Sie dies auf https://api.x.com/1.1/account/verify_credentials.json. Auf iOS5 basierende X-Integrationen fügen dieser URL einen zusätzlichen application_id-Parameter hinzu, der auch zur Berechnung der oauth_signature verwendet wird, die in x-verify-credentials-authorization verwendet wird.
• x-verify-credentials-authorization — Der Consumer sollte alle notwendigen OAuth-Parameter erstellen, sodass er https://api.x.com/1.1/account/verify_credentials.json mit OAuth im HTTP-Header aufrufen könnte (z. B. sollte es aussehen wie OAuth oauth_consumer_key=”…”, oauth_token=”…”, oauth_signature_method=”…”, oauth_signature=”…”, oauth_timestamp=”…”, oauth_nonce=”…”, oauth_version=”…”).  

Beachten Sie, dass die gesamte Transaktion innerhalb eines Zeitraums stattfinden muss, in dem der oauth_timestamp noch gültig ist.

Alternativ können diese beiden Parameter statt im Header auch im POST als x_auth_service_provider und x_verify_credentials_authorization gesendet werden — denken Sie in diesem Fall daran, die Parameter in die OAuth-Signatur-Basiszeichenkette zu escapen und einzubeziehen — ähnlich wie beim Kodieren von Parametern in jeder Anfrage. Es ist am besten, HTTP-Header zu verwenden, um die Vorgänge so getrennt wie möglich zu halten.

Das Ziel des Delegators ist es an diesem Punkt, zu überprüfen, dass der Nutzer derjenige ist, für den er sich ausgibt, bevor die Medien gespeichert werden. Sobald der Delegator alle oben genannten data über seine Upload-Methode erhält, sollte er das Bild vorübergehend speichern und dann einen Aufruf an den im x-auth-service-provider-Header angegebenen endpoint konstruieren — in diesem Fall https://api.x.com/1.1/account/verify_credentials.json — unter Verwendung desselben OAuth-Authentifizierungs-Headers, der vom Consumer im x-verify-credentials-authorization-Header bereitgestellt wurde.  

​

Best Practices für OAuth Echo

Verwenden Sie die vom x-auth-service-provider bereitgestellte URL für das Lookup, nicht einen hartcodierten Wert. Apple iOS fügt beispielsweise allen OAuth-Anfragen einen zusätzlichen Parameter application_id hinzu, und dessen Vorhandensein sollte in jeder Phase von OAuth Echo beibehalten werden.

Für den OAuth-Autorisierungsteil nehmen Sie den Headerwert aus x-verify-credentials-authorization und setzen ihn als eigenen Authorization-Header für den Aufruf an den Service Provider. Überprüfen Sie der Vollständigkeit halber, dass der Wert in x-auth-service-provider korrekt ist.

• Wenn der Service Provider einen HTTP 200 zurückgibt, ist das in Ordnung. Der Delegator sollte das Bild dauerhaft speichern, eine URL generieren und diese zurückgeben.
• Wenn der Service Provider keinen HTTP 200 zurückgibt, verwerfen Sie das Bild und geben Sie anschließend einen Fehler an den Consumer zurück.