repo_zf1/documentation/manual/de/module_specs/Zend_Oauth-ProtocolWorkflow.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- EN-Revision: 20232 -->
<!-- Reviewed: no -->
<sect2 id="zend.oauth.introduction.protocol-workflow">
    <title>Workflow des Protokolls</title>

    <para>
        Bevor OAuth implementiert wird macht es Sinn zu verstehen wie das Protokoll arbeitet.
        Hierfür nehmen wir ein Beispiel von Twitter welches aktuell bereits OAuth basierend auf der
        OAuth Core 1.0 Revision A Spezifikation imeplementiert. Dieses Beispiel sieht das Protokoll
        aus der Perspektive des Benutzers (der den Zugriff gestattet), dem Konsumenten (der den
        Zugriff anfragt) und dem Provider (der die privaten Daten des Benutzers hat). Ein Zugriff
        kann nur-lesend, oder lesend und schreibend sein.
    </para>

    <para>
        Durch Zufall hat unser Benutzer entschieden das er einen neuen Service verwenden will der
        TweetExpress genannt wird und behauptet in der Lage zu sein Blog Posts bei Twitter in
        wenigen Sekunden nochmals zu posten. TweetExpress ist bei Twitter eine registrierte
        Anwendung was bedeutet das es Zugriff auf einen Konsumentenschlüssel und ein Geheimnis des
        Konsumenten hat (alle OAuth Anwendungen müssen diese vom Provider haben auf welchen Sie
        zugreifen wollen) welche seine Anfragen bei Twitter identifizieren und sicherstellen das
        alle Anfragen signiert werden können indem das Geheimnis des Konsumenten verwendet wird um
        deren Herkunft zu prüfen.
    </para>

    <para>
        Um TweetExpress zu verwenden wird man danach gefragt sich für einen neuen Account zu
        registrieren, und das der Registrierung wird sichergestellt das man dafüber informiert ist
        das TweetExpress den eigenen Twitter Account mit dem Service assoziiert.
    </para>

    <para>
        In the meantime TweetExpress has been busy. Before gaining your approval from Twitter, it
        has sent a HTTP request to Twitter's service asking for a new unauthorized Request Token.
        This token is not User specific from Twitter's perspective, but TweetExpress may use it
        specifically for the current User and should associate it with their account and store it
        for future use. TweetExpress now redirects the User to Twitter so they can approve
        TweetExpress' access. The URL for this redirect will be signed using TweetExpress' Consumer
        Secret and it will contain the unauthorized Request Token as a parameter.
    </para>

    <para>
        At this point the User may be asked to log into Twitter and will now be faced with a Twitter
        screen asking if they approve this request by TweetExpress to access Twitter's API on the
        User's behalf. Twitter will record the response which we'll assume was positive. Based on
        the User's approval, Twitter will record the current unauthorized Request Token as having
        been approved by the User (thus making it User specific) and will generate a new value in
        the form of a verification code. The User is now redirected back to a specific callback URL
        used by TweetExpress (this callback URL may be registered with Twitter or dynamically set
        using an oauth_callback parameter in requests). The redirect URL will contain the newly
        generated verification code.
    </para>

    <para>
        TweetExpress' callback URL will trigger an examination of the response to determine whether
        the User has granted their approval to Twitter. Assuming so, it may now exchange it's
        unauthorized Request Token for a fully authorized Access Token by sending a request back to
        Twitter including the Request Token and the received verification code.  Twitter should now
        send back a response containing this Access Token which must be used in all requests used to
        access Twitter's API on behalf of the User. Twitter will only do this once they have
        confirmed the attached Request Token has not already been used to retrieve another Access
        Token. At this point, TweetExpress may confirm the receipt of the approval to the User and
        delete the original Request Token which is no longer needed.
    </para>

    <para>
        From this point forward, TweetExpress may use Twitter's API to post new tweets on the User's
        behalf simply by accessing the API endpoints with a request that has been digitally signed
        (via HMAC-SHA1) with a combination of TweetExpress' Consumer Secret and the Access Key being
        used.
    </para>

    <para>
        Although Twitter do not currently expire Access Tokens, the User is free to deauthorize
        TweetExpress from their Twitter account settings.  Once deauthorized, TweetExpress' access
        will be cut off and their Access Token rendered invalid.
    </para>
</sect2>