Authentifizierung und Autorisierung im Google Data Protocol

Warnung: Auf dieser Seite geht es um die älteren APIs von Google, die Google Data APIs. Sie ist nur für die APIs relevant, die im Google Data APIs-Verzeichnis aufgeführt sind. Viele davon wurden durch neuere APIs ersetzt. Informationen zu einer bestimmten neuen API finden Sie in der Dokumentation der jeweiligen API. Informationen zum Autorisieren von Anfragen mit einer neueren API finden Sie unter Authentifizierung und Autorisierung von Google-Konten.

Drittanbieter-Apps benötigen für bestimmte Arten von Aktivitäten häufig eingeschränkten Zugriff auf das Google-Konto eines Nutzers. Damit Nutzerdaten nicht missbraucht werden, müssen alle Zugriffsanfragen vom Kontoinhaber genehmigt werden. Die Zugriffssteuerung besteht aus zwei Komponenten: Authentifizierung und Autorisierung.

Mit Authentifizierungsdiensten können sich Nutzer mit einem Google-Konto in Ihrer Anwendung anmelden.

Mit Autorisierungsdiensten können Nutzer Ihrer Anwendung Zugriff auf die Daten gewähren, die sie in Google-Anwendungen gespeichert haben. Google nimmt den Datenschutz sehr ernst. Jede Anwendung, die Zugriff auf die Daten eines Nutzers benötigt, muss vom Nutzer autorisiert werden.

Authentifizierungs- und Autorisierungsdienste werden oft zusammenfassend als Auth bezeichnet.

Durch die Authentifizierung und Autorisierung für Google APIs können Drittanbieteranwendungen eingeschränkten Zugriff auf das Google-Konto eines Nutzers für bestimmte Arten von Aktivitäten erhalten. In diesem Dokument werden die verfügbaren Authentifizierungsmechanismen vorgestellt und es wird beschrieben, was die einzelnen Mechanismen für Ihre Anwendung bieten.

  • Mit Google Log-in können Nutzer sich ganz einfach mit ihren Google-Anmeldedaten auf Ihrer Website anmelden. Es enthält eine Reihe von Tools, die sich einfach in verschiedene Geräte integrieren lassen.
  • OAuth 2.0 ist ein Autorisierungsprotokoll für alle Google APIs. OAuth 2.0 greift für die Sicherheit auf SSL zurück und ist leichter zu implementieren. Ihre Anwendung muss also keine direkte kryptografische Signierung vornehmen. Mit diesem Protokoll kann Ihre Anwendung Zugriff auf Daten anfordern, die mit dem Google-Konto eines Nutzers verknüpft sind.
  • Bei der Anmeldung mit OAuth 2.0 (OpenID Connect) werden Nutzer authentifiziert, indem sie sich mit ihren Google-Konten anmelden. Dies ist ein Ersatz für OpenID. Nutzer von OpenID sollten eine Migration zu „Mit OAuth 2.0 anmelden“ planen.

Wenn Ihre Anwendung ein Gadget ist (zur Verwendung in iGoogle oder anderen OpenSocial-Containern), lesen Sie den Abschnitt Authentifizierung für Gadgets.

Hinweis: Dieses Dokument soll einen Überblick über die einzelnen Authentifizierungsmethoden geben. Ausführliche Informationen zu den einzelnen Methoden finden Sie in der vollständigen Dokumentation zu den Google Account Authentication APIs.

Weitere Informationen zur Verwendung der Google Accounts APIs finden Sie auch in der Google Accounts API Group.

OAuth – Autorisierung für Web- und installierte Anwendungen

Viele Google-Dienste ermöglichen Drittanbietern den Zugriff auf nutzergenerierte Daten wie Kalender- oder Dokumentdaten, sofern der Zugriff vom Nutzer autorisiert wird. Mit dieser Funktion können Nutzer Daten zwischen ihren Google-Anwendungen und Drittanbieteranwendungen für verschiedene Zwecke teilen und austauschen.

Google unterstützt zwei Versionen von OAuth für den autorisierten Zugriff auf die Google-Daten eines Nutzers: OAuth 1.0 und OAuth 2.0. Beide bieten Zugriff auf Webanwendungen und installierte Anwendungen.

OAuth 2.0 für Webanwendungen und installierte Anwendungen

Webanwendungen oder installierte Anwendungen können das neue, vereinfachte OAuth 2.0-Protokoll verwenden, um den Zugriff auf Daten zu autorisieren, die mit einem Google-Konto verknüpft sind. Weitere Informationen und Beispiele zur Implementierung von OAuth 2.0 mit Google finden Sie in unserer Dokumentation zu OAuth 2.0.

OAuth 1.0 für Webanwendungen

Webanwendungen, die autorisierten Zugriff auf Daten benötigen, die mit einem Google-Konto oder einem Google Apps-Konto verknüpft sind, können die Implementierung der OAuth API von Google verwenden. Vollständige Informationen zur Implementierung von OAuth für webbasierte Anwendungen, einschließlich Beispielen, finden Sie im Leitfaden OAuth für Web-Apps oder in der Übersicht in diesem Dokument.

OAuth 1.0 für installierte Anwendungen

Anwendungen, die auf den Computern und Mobilgeräten von Nutzern installiert sind, können OAuth verwenden, um den Zugriff auf Daten zu autorisieren, die mit einem Google-Konto verknüpft sind. Vollständige Informationen zur Implementierung von OAuth für installierte Anwendungen finden Sie im Leitfaden OAuth for Installed Applications oder in der Übersicht in diesem Dokument.

OAuth mit Webanwendungen verwenden

Alle Google Data APIs unterstützen OAuth, einen offenen Standard für die Autorisierung der Verwendung von Daten in Webanwendungen. Alle Webanwendungen, die OAuth-Anfragen stellen, müssen ein Sicherheitszertifikat hochladen und sich bei Google registrieren. Weitere Informationen finden Sie unter Registrierung für webbasierte Anwendungen.

Die Google Data APIs-Clientbibliotheken enthalten Methoden, mit denen Sie OAuth in Ihrer Webanwendung verwenden können. Es gibt Methoden zum Erstellen des Anfrage-Tokens, zum Autorisieren des Anfrage-Tokens und zum Tauschen des autorisierten Anfrage-Tokens gegen ein Zugriffstoken. Die Bibliotheken verarbeiten auch die erforderlichen Signaturalgorithmen, wenn Anfragen an einen Google-Datendienst gesendet werden. Ausführliche Beispiele für die Verwendung von OAuth mit den Google Data API-Clientbibliotheken finden Sie unter OAuth mit den Google Data APIs-Clientbibliotheken verwenden.

Der OAuth-Autorisierungsprozess

Der OAuth-Autorisierungsprozess umfasst eine Reihe von Interaktionen zwischen Ihrer Webanwendung, den Autorisierungsservern von Google und dem Endnutzer.

Der Prozess läuft im Grunde so ab:

  1. Ihre Anwendung fordert Zugriff an und erhält ein nicht autorisiertes Anfragetoken vom Autorisierungsserver von Google.
  2. Google bittet den Nutzer, Ihnen Zugriff auf die erforderlichen Daten zu gewähren.
  3. Ihre Anwendung erhält ein autorisiertes Anfragetoken vom Autorisierungsserver.
  4. Sie tauschen das autorisierte Anfragetoken gegen ein Zugriffstoken ein.
  5. Mit dem Zugriffstoken fordern Sie Daten von den Google-Servern an.

Wenn Ihre Anwendung zum ersten Mal Zugriff auf die Daten eines Nutzers anfordert, stellt Google ein nicht autorisiertes Anforderungstoken für Ihre Anwendung aus.

Wenn der Nutzer noch nicht angemeldet ist, wird er von Google aufgefordert, sich anzumelden. Google zeigt dann eine Autorisierungsseite an, auf der der Nutzer sehen kann, auf welche Google-Dienstdaten Ihre Anwendung Zugriff anfordert.

Wenn der Nutzer den Zugriffsantrag Ihrer Anwendung genehmigt, stellt Google ein autorisiertes Antrags-Token aus. Jedes Anfragetoken ist nur eine Stunde lang gültig. Nur ein autorisiertes Anfragetoken kann gegen ein Zugriffstoken eingetauscht werden. Dieser Tausch kann nur einmal pro autorisiertem Anfragetoken erfolgen.

Standardmäßig haben Zugriffstokens eine lange Lebensdauer. Jedes Zugriffstoken ist spezifisch für das Nutzerkonto, das in der ursprünglichen Autorisierungsanfrage angegeben wurde, und gewährt nur Zugriff auf die in dieser Anfrage angegebenen Dienste. Ihre Anwendung sollte das Zugriffstoken sicher speichern, da es für jeden Zugriff auf die Daten eines Nutzers erforderlich ist.

Vorbereitung auf OAuth

Bevor Sie Ihre Anwendung für die Verwendung des Google-Autorisierungsdienstes mit OAuth einrichten können, müssen Sie die folgenden Aufgaben ausführen.

Entscheiden, ob Sie Ihre Webanwendung registrieren möchten

Um Ihren Nutzern zusätzliche Sicherheit für ihre Daten zu bieten, können Sie Ihre Webanwendung bei Google registrieren und Ihre Anfragen mit dem registrierten Sicherheitszertifikat signieren. Einige Google Data API-Feeds sind nur für registrierte Anwendungen verfügbar. In der Dokumentation der Google Data API, die Sie verwenden möchten, finden Sie Informationen dazu, ob die API nur mit registrierten Anwendungen funktioniert.

Ihre Anwendung muss jede OAuth-Anfrage signieren, die sie stellt. Wenn Sie Ihre Anfragen mit einer RSA-SHA1-Signatur signieren möchten, müssen Sie im Rahmen des Registrierungsprozesses ein Sicherheitszertifikat hochladen.

Alternativ können Sie Ihre Anfragen mit einer HMAC-SHA1-Signatur signieren. Für HMAC-SHA1-Signaturen ist kein Zertifikat erforderlich. Stattdessen generiert Google einen OAuth-consumer secret-Wert, der nach der Registrierung auf der Registrierungsseite Ihrer Domain angezeigt wird.

Weitere Informationen zum Registrierungsprozess finden Sie unter Registrierung für Webanwendungen.

Umfang der Daten ermitteln, auf die Ihre Anwendung zugreifen wird

Für jeden Google-Dienst gelten Beschränkungen für den Zugriff, der über die Google Data APIs möglich ist. Dieser Zugriff wird als Bereichswert ausgedrückt. Einige Dienste bieten eine Vielzahl von Bereichswerten, damit Nutzer auswählen können, welche Anwendungen auf welche Daten zugreifen dürfen. Informationen zu den verfügbaren Bereichswerten für den Google-Dienst, auf den Sie zugreifen möchten, finden Sie in der Dokumentation zu diesem Dienst.

Im Allgemeinen sollten Sie ein Token für den engsten Bereich anfordern, der die benötigten Daten umfasst. Wenn Ihre Anwendung beispielsweise Zugriff auf den Feed „Alle Kalender“ des Nutzers benötigt, sollten Sie ein Token für den Bereich http://www.google.com/calendar/feeds/default/allcalendars/full anfordern.

Mechanismus zum Verwalten von OAuth-Tokens einrichten

Wenn Sie ein OAuth-Zugriffstoken für die Daten eines Nutzers abrufen, müssen Sie dieses Zugriffstoken für alle zukünftigen Interaktionen mit dem angegebenen Google-Dienst im Namen des Nutzers verwenden.

Ihre Anwendung sollte die Speicherung von Tokens sicher verwalten und dabei auch den Google-Dienst erfassen, für den jedes Token gültig ist. Wenn Sie Zugriff auf mehrere Google-Dienste benötigen, können Sie mehrere Zugriffstokens erhalten. Es dürfen jedoch nicht mehr als zehn Zugriffstokens pro Nutzer und Anwendung gleichzeitig ausstehen.

Wenn Ihre Anwendung mehrere Nutzerkonten unterstützt, müssen Sie nachverfolgen, welchem Konto jedes Token zugeordnet ist. Jedes OAuth-Token ist spezifisch für den Nutzer, der den Zugriff autorisiert hat. Ihre Anwendung muss ein Token dem richtigen Nutzer zuordnen können. Eine Möglichkeit, dies zu umgehen, besteht darin, dem Nutzer ein Cookie auszustellen, bevor die Tokenanfrage gesendet wird. Nachdem der Nutzer den Zugriff auf die angeforderten Daten gewährt hat, sendet Google ein autorisiertes Anfragetoken und leitet den Nutzer zu Ihrer Anwendung weiter. Anschließend können Sie das Cookie Ihrer Anwendung verwenden, um das Token dem richtigen Nutzer zuzuordnen.

Mechanismus zum Anfordern des Zugriffs auf einen Google-Dienst einrichten

Jede Anfrage an einen Google-Dienst muss signiert sein und ein gültiges OAuth-Zugriffstoken enthalten. Im Allgemeinen wird jede Anfrage in Form einer HTTP-GET-Anfrage gestellt, wobei das Zugriffstoken und die Signatur im Header enthalten sind. Für Anfragen, mit denen neue Daten geschrieben werden, sollte HTTP POST verwendet werden.

Weitere Informationen zum richtigen Anfrageformat für die einzelnen Google Data APIs finden Sie in der Dokumentation zur jeweiligen API.

OpenID implementieren (optional)

Wenn Sie OpenID für die Nutzerauthentifizierung implementieren, sollten Sie das Hybridprotokoll verwenden, um die beiden Prozesse zu kombinieren. Bei OpenID+OAuth werden die Aufgaben zum Abrufen und Autorisieren eines Anfragetokens im Rahmen der OpenID-Anfrage mit OAuth-Erweiterungen ausgeführt. Wie bei OAuthGetRequestToken werden diese Erweiterungen verwendet, um die Google-Dienste zu identifizieren, auf die zugegriffen werden soll. Eine erfolgreiche Antwort auf die OpenID-Anfrage enthält ein autorisiertes Anfrage-Token. Sobald Sie dieses Token erhalten haben, verwenden Sie OAuthGetAccessToken, um es gegen ein Zugriffstoken einzutauschen.

Mit OAuth-Tokens arbeiten

Wenn Sie OAuth verwenden möchten, muss Ihre Anwendung wohlgeformte, signierte Tokenanfrageaufrufe generieren und die Antworten für die folgende Sequenz verarbeiten:

  1. Nicht autorisiertes Anfrage-Token abrufen (OAuthGetRequestToken)
  2. Anfragetoken (OAuthAuthorizeToken) autorisieren
  3. Autorisiertes Anfrage-Token gegen ein Zugriffstoken eintauschen (OAuthGetAccessToken)

Alle OAuth-Anfragen müssen signiert werden, unabhängig davon, ob Ihre Anwendung registriert ist. Weitere Informationen finden Sie unter OAuth-Anfragen signieren.

Im OAuth Playground können Sie das Anfordern und Empfangen von Autorisierungstokens ausprobieren.

Eine detaillierte Dokumentation finden Sie in der OAuth API-Referenz.

Callback-URL festlegen

Sie können in einer OAuthGetRequestToken-Anfrage einen Wert für oauth_callback angeben, um festzulegen, wohin Google den Nutzer weiterleitet, nachdem er Ihre Zugriffsanfrage autorisiert hat. Die Callback-URL kann Suchparameter enthalten. Die Weiterleitung enthält dieselben Abfrageparameter sowie das autorisierte Anfragetoken, das Ihre Anwendung parsen können muss.

Wenn Sie beispielsweise mehrere Sprachen unterstützen, können Sie einen Abfrageparameter einfügen, der die Version der Anwendung angibt, die ein Nutzer aufruft. Ein oauth_callback-Wert von „http://www.yoursite.com/Retrievetoken?Lang=de“ führt zur Weiterleitung „http://www.yoursite.com/Retrievetoken?Lang=de&oauth_token=DQAADKEDE“. Durch das Parsen des Tokens und des Sprachparameters wird sichergestellt, dass der Nutzer zur richtigen Version der Website weitergeleitet wird.

Wenn der Parameter oauth_callback nicht enthalten ist, leitet Google den Nutzer nach der Autorisierung Ihrer Zugriffsanfrage auf eine Webseite weiter, auf der eine Bestätigungsnummer angezeigt wird (siehe Beispiel). Der Nutzer muss manuell zu Ihrer Anwendung zurückkehren und die Bestätigungsnummer eingeben, bevor Sie ein autorisiertes Anfragetoken erhalten können.

Nutzer über Ihre Anwendung informieren

Normalerweise zeigt Google den Namen einer Anwendung an, wenn die Zustimmung des Nutzers für den Zugriff angefordert wird (siehe Beispiel).

Wenn Ihre Anwendung nicht registriert ist, verwenden Sie den Parameter xoauth_displayname in Ihrer OAuthGetRequestToken-Anfrage, um den Namen Ihrer Anwendung anzugeben. Wenn dieser Parameter nicht angegeben ist, zeigt Google den Domainnamen der URL an, die mit dem Parameter oauth_callback angegeben wurde. Wenn keine Callback-URL angegeben ist, zeigt Google den String „anonymous“ an.

Legen Sie diesen Parameter nicht fest, wenn Ihre Anwendung registriert ist. Standardmäßig zeigt Google den bei der Registrierung angegebenen Anzeigenamen an. Wenn Sie in Ihrer OAuthGetRequestToken-Anfrage einen Anzeigenamen festlegen, verwendet Google diesen anstelle Ihres registrierten Anzeigenamens und fügt eine Meldung hinzu, dass die Identität Ihrer Anwendung nicht bestätigt werden kann.

Hinweis:Wenn Sie den Parameter xoauth_displayname im OAuth Playground festlegen möchten, müssen Sie das Kästchen „Erweitert“ aktivieren, bevor Sie das Anfragetoken abrufen.

Mit Google Apps-Domains arbeiten

Wenn Ihre Anwendung für Nutzer in einer von Google gehosteten Domain mit Google-Konten entwickelt wurde, sollten Sie den Parameter hd verwenden, wenn Sie ein Token autorisieren. Weitere Informationen zum Parameter hd finden Sie unter Nutzer mit mehreren Konten verarbeiten.

Weitere Informationen zu OAuth

Ausführliche Informationen zur Implementierung von OAuth durch Google, einschließlich der Registrierung Ihrer Anwendung und der Erstellung der erforderlichen OAuth-Parameter, finden Sie in den folgenden zusätzlichen Ressourcen:

Nach oben

OAuth mit installierten Anwendungen verwenden

Alle Google Data APIs unterstützen OAuth, einen offenen Standard für die Autorisierung der Verwendung von Daten in Anwendungen. Installierte Anwendungen müssen nicht bei Google registriert werden, um OAuth zu verwenden.

Der OAuth-Autorisierungsprozess

Der OAuth-Autorisierungsprozess umfasst eine Reihe von Interaktionen zwischen Ihrer Anwendung, den Autorisierungsservern von Google und dem Endnutzer.

Der Prozess läuft im Grunde so ab:

  1. Ihre Anwendung fordert Zugriff an und erhält ein nicht autorisiertes Anfragetoken vom Autorisierungsserver von Google.
  2. Google bittet den Nutzer, Ihnen Zugriff auf die erforderlichen Daten zu gewähren.
  3. Ihre Anwendung erhält ein autorisiertes Anfragetoken vom Autorisierungsserver.
  4. Sie tauschen das autorisierte Anfragetoken gegen ein Zugriffstoken ein.
  5. Mit dem Zugriffstoken fordern Sie Daten von den Google-Servern an.

Wenn Ihre Anwendung zum ersten Mal Zugriff auf die Daten eines Nutzers anfordert, stellt Google ein nicht autorisiertes Anforderungstoken für Ihre Anwendung aus.

Wenn der Nutzer noch nicht angemeldet ist, wird er von Google aufgefordert, sich anzumelden. Google zeigt dann eine Autorisierungsseite an, auf der der Nutzer sehen kann, auf welche Google-Dienstdaten Ihre Anwendung Zugriff anfordert.

Wenn der Nutzer den Zugriffsantrag Ihrer Anwendung genehmigt, stellt Google ein autorisiertes Antrags-Token aus. Jedes Anfragetoken ist nur eine Stunde lang gültig. Nur ein autorisiertes Anfragetoken kann gegen ein Zugriffstoken eingetauscht werden. Dieser Tausch kann nur einmal pro autorisiertem Anfragetoken erfolgen.

OAuth unterstützt installierte Anwendungen im nicht registrierten Modus. Da es verschiedene Methoden zum Abrufen eines autorisierten Anfragetokens gibt, kann Ihre App OAuth zur Autorisierung einer Anwendung verwenden, auch wenn auf dem Gerät, auf dem sie installiert ist, kein Webbrowser vorhanden ist.

Standardmäßig haben Zugriffstokens eine lange Lebensdauer. Jedes Zugriffstoken ist spezifisch für das Nutzerkonto, das in der ursprünglichen Autorisierungsanfrage angegeben wurde, und gewährt nur Zugriff auf die in dieser Anfrage angegebenen Dienste. Ihre Anwendung sollte das Zugriffstoken sicher speichern, da es für jeden Zugriff auf die Daten eines Nutzers erforderlich ist.

Vorbereitung auf OAuth

Bevor Sie Ihre Anwendung für die Verwendung des Google-Autorisierungsdienstes mit OAuth einrichten können, müssen Sie die folgenden Aufgaben ausführen.

Umfang der Daten ermitteln, auf die Ihre Anwendung zugreifen wird

Für jeden Google-Dienst gelten Beschränkungen für den Zugriff, der über die Google Data APIs möglich ist. Dieser Zugriff wird als Bereichswert ausgedrückt. Einige Dienste bieten eine Vielzahl von Bereichswerten, damit Nutzer auswählen können, welche Anwendungen auf welche Daten zugreifen dürfen. Informationen zu den verfügbaren Bereichswerten für den Google-Dienst, auf den Sie zugreifen möchten, finden Sie in der Dokumentation zu diesem Dienst.

Im Allgemeinen sollten Sie ein Token für den engsten Bereich anfordern, der die benötigten Daten umfasst. Wenn Ihre Anwendung beispielsweise Zugriff auf den Feed „Alle Kalender“ des Nutzers benötigt, sollten Sie ein Token für den Bereich http://www.google.com/calendar/feeds/default/allcalendars/full anfordern.

Mechanismus zum Verwalten von OAuth-Tokens einrichten

Wenn Sie ein OAuth-Zugriffstoken für die Daten eines Nutzers abrufen, müssen Sie dieses Zugriffstoken für alle zukünftigen Interaktionen mit dem angegebenen Google-Dienst im Namen des Nutzers verwenden.

Ihre Anwendung sollte die Speicherung von Tokens sicher verwalten und dabei auch den Google-Dienst erfassen, für den jedes Token gültig ist.

Wenn Ihre Anwendung mehrere Nutzerkonten unterstützt, müssen Sie nachverfolgen, welchem Konto jedes Token zugeordnet ist.

Mechanismus zum Anfordern des Zugriffs auf einen Google-Dienst einrichten

Jede Anfrage an einen Google-Dienst muss signiert sein und ein gültiges OAuth-Zugriffstoken enthalten. Im Allgemeinen wird jede Anfrage in Form einer HTTP-GET-Anfrage gestellt, wobei das Zugriffstoken und die Signatur im Header enthalten sind. Für Anfragen, mit denen neue Daten geschrieben werden, sollte HTTP POST verwendet werden.

Weitere Informationen zum richtigen Anfrageformat für die einzelnen Google Data APIs finden Sie in der Dokumentation zur jeweiligen API.

Mit OAuth-Tokens arbeiten

Wenn Sie OAuth verwenden möchten, muss Ihre Anwendung wohlgeformte, signierte Tokenanfrageaufrufe generieren und die Antworten für die folgende Sequenz verarbeiten:

  1. Nicht autorisiertes Anfrage-Token abrufen (OAuthGetRequestToken)
  2. Anfragetoken (OAuthAuthorizeToken) autorisieren
  3. Autorisiertes Anfrage-Token gegen ein Zugriffstoken eintauschen (OAuthGetAccessToken)

Alle OAuth-Anfragen müssen signiert werden, unabhängig davon, ob Ihre Anwendung registriert ist. Weitere Informationen finden Sie unter OAuth-Anfragen signieren. Für installierte Anwendungen gelten die Anweisungen für nicht registrierte Anwendungen.

Im OAuth Playground können Sie das Anfordern und Empfangen von Autorisierungstokens ausprobieren.

Eine detaillierte Dokumentation finden Sie in der OAuth API-Referenz.

Nutzer über Ihre Anwendung informieren

Normalerweise zeigt Google den Namen einer Anwendung an, wenn die Zustimmung des Nutzers für den Zugriff angefordert wird (siehe Beispiel).

Verwenden Sie den Parameter xoauth_displayname in Ihrer OAuthGetRequestToken-Anfrage, um den Namen Ihrer Anwendung anzugeben. Wenn dieser Parameter nicht angegeben ist, zeigt Google den Domainnamen der URL an, die mit dem Parameter oauth_callback angegeben wurde. Wenn keine Callback-URL angegeben ist, zeigt Google den String „anonymous“ an.

Hinweis:Wenn Sie den Parameter xoauth_displayname im OAuth Playground festlegen möchten, müssen Sie das Kästchen „Erweitert“ aktivieren, bevor Sie das Anfragetoken abrufen.

Webbrowser starten

Im Rahmen des OAuth-Autorisierungsprozesses muss Ihre Anwendung eine OAuthAuthorizeToken-Anfrage stellen. Der Nutzer muss sich dann auf einer Google-Webseite anmelden und die Zugriffsanfrage Ihrer Anwendung autorisieren.

  • Der AutoDetect-Modus sollte für die meisten Anwendungen verwendet werden.
  • Der Gerätemodus sollte für Anwendungen verwendet werden, die keinen vollständigen Webbrowser starten können.
  • Der Entwicklungsmodus sollte nur in der frühen Entwicklungsphase verwendet werden.

Modus „Automatische Erkennung“

Ihre Anwendung sollte nach Möglichkeit ein Browserfenster öffnen und eine OAuthAuthorizeToken-Anfrage senden, um die Google-Seite zu öffnen. Wenn Google das autorisierte Token zurückgibt, sollte Ihre Anwendung dies erkennen und den Fokus vom Webbrowser zurückerhalten.

In diesem Modus müssen Sie eine Callback-URL angeben, an die der Nutzer weitergeleitet wird, nachdem er Ihre Zugriffsanfrage autorisiert hat. Diese URL muss als oauth_callback-Parameter der OAuthGetRequestToken-Anfrage und als verifier-Parameter der OAuthGetAccessToken-Anfrage angegeben werden.

Um die Nutzerfreundlichkeit zu verbessern, sollte Ihre Anwendung versuchen, automatisch zu erkennen, wenn der Nutzer zu dieser URL weitergeleitet wird. Sie sollte sich dann sofort in den Vordergrund bringen und eine OAuthGetAccessToken-Anfrage senden, um den OAuth-Prozess abzuschließen.

Weitere Informationen und Best Practices finden Sie unter Automatische Erkennung der Genehmigung.

Wenn Ihre Anwendung nicht automatisch erkennen kann, wann der Nutzer zur Callback-URL weitergeleitet wird, oder sich nicht in den Vordergrund bringen kann, sollte die Callback-URL eine Seite anzeigen, auf der erklärt wird, wie Ihre Anwendung in den Vordergrund gebracht und die OAuthGetAccessToken-Anfrage in Ihrer Anwendung initiiert werden kann.

Gerätemodus

Wenn Ihre Anwendung keinen vollständigen Webbrowser starten kann, ist es auch möglich, dass Rich-Client-Geräte ohne Webbrowser autorisiert werden.

In diesem Modus kann ein Entwickler eine Website einrichten, auf der ein Nutzer die Zugriffsanfrage autorisieren kann. Nach der Autorisierung erhält der Nutzer einen von Google generierten Code und wird zur Website des Entwicklers weitergeleitet. Auf dieser Website sollte dem Nutzer erklärt werden, wie er den Code auf seinem Gerät eingibt, um den Autorisierungsvorgang abzuschließen.

Entwicklungsmodus

Dieser Modus wird nur für die frühe Entwicklungsphase einer Anwendung empfohlen.

Wie im AutoDetect-Modus muss Ihre Anwendung einen Browser starten und der Nutzer muss Ihre Anfrage autorisieren. Anstatt eine Webseite für die Callback-URL zu erstellen, können Sie den Wert des Parameters oauth_callback auf "oob" (out-of-band) festlegen.

Nachdem der Nutzer Ihre Anfrage autorisiert hat, leitet Google ihn in diesem Fall zu einer Google-Konten-Seite weiter, auf der eine Bestätigungsnummer angezeigt wird (Beispiel).

Der Nutzer muss zu Ihrer Anwendung zurückkehren und die Bestätigungsnummer eingeben, bevor Sie eine OAuthGetAccessToken-Anfrage stellen können.

Weitere Informationen zu OAuth

Ausführliche Informationen zur Implementierung von OAuth durch Google, einschließlich der Registrierung Ihrer Anwendung und der Erstellung der erforderlichen OAuth-Parameter, finden Sie in den folgenden zusätzlichen Ressourcen:

Nach oben

AuthSub zur Autorisierung verwenden

AuthSub ist eine von Google entwickelte Autorisierungs-API, die für die meisten Google APIs als Alternative zu OAuth verfügbar ist. Sie sollten AuthSub nach Möglichkeit nicht verwenden. Wenn Sie bereits Anwendungen haben, die AuthSub verwenden, sollten Sie zu OAuth oder zum Hybridprotokoll migrieren.

AuthSub-Autorisierungsprozess

Die Autorisierung mit AuthSub umfasst eine Reihe von Interaktionen zwischen drei Einheiten: der Webanwendung, Google-Diensten und dem Nutzer. Das folgende Diagramm veranschaulicht die Sequenz:

Autorisierungsprozess

  1. Wenn die Webanwendung auf einen Google-Dienst eines Nutzers zugreifen muss, führt sie einen AuthSub-Aufruf an den Autorisierungsproxy-Dienst von Google aus.
  2. Der Autorisierungsdienst antwortet mit einer Seite für den Zugriff auf Anfragen. Auf dieser von Google verwalteten Seite wird der Nutzer aufgefordert, den Zugriff auf seinen Google-Dienst zu gewähren oder zu verweigern. Der Nutzer wird möglicherweise zuerst aufgefordert, sich in seinem Konto anzumelden.
  3. Der Nutzer entscheidet, ob er den Zugriff auf die Webanwendung gewährt oder verweigert. Wenn der Nutzer den Zugriff verweigert, wird er auf eine Google-Seite weitergeleitet und nicht zurück zur Webanwendung.
  4. Wenn der Nutzer den Zugriff gewährt, leitet der Autorisierungsdienst den Nutzer zurück zur Webanwendung. Die Weiterleitung enthält ein Autorisierungstoken, das einmal verwendet werden kann und gegen ein langlebiges Token eingetauscht werden kann.
  5. Die Webanwendung kontaktiert den Google-Dienst mit einer Anfrage und verwendet das Autorisierungstoken, um als Agent für den Nutzer zu fungieren.
  6. Wenn der Google-Dienst das Token erkennt, werden die angeforderten Daten bereitgestellt.

Mit AuthSub arbeiten

Um AuthSub in Ihre Webanwendung einzubinden, sind folgende Aufgaben erforderlich:

  1. Entscheiden Sie, ob Sie Ihre Webanwendung registrieren möchten.

    Registrierte Webanwendungen haben den Vorteil, dass sie von Google erkannt werden. Der Standardhinweis, der Nutzern auf der Google-Anmeldeseite angezeigt wird, wird geändert oder weggelassen. Außerdem werden registrierte Webanwendungen nicht nur anhand der aufrufenden URL, sondern auch anhand eines beschreibenden Namens identifiziert. Beachten Sie, dass einige Google-Dienste nur eingeschränkten Zugriff auf nicht registrierte Webanwendungen zulassen. Wenn Sie sich registrieren möchten, verwenden Sie diesen automatisierten Registrierungsprozess.

    Wenn Sie sich registrieren, können Sie auch ein Sicherheitszertifikat und Schlüssel angeben. Registrierte Webanwendungen mit einem hinterlegten Zertifikat können sichere Tokens abrufen, die zum Anfordern von Daten von einem Google-Dienst verwendet werden. Bei Bedarf können sie auch nicht sichere Tokens verwenden.

  2. Entscheiden Sie, welche Art von Tokens Sie verwenden möchten und wie Sie sie verwalten.

    Ein von Google empfangenes Autorisierungstoken ist für alle zukünftigen Interaktionen mit dem angegebenen Google-Dienst für diesen Nutzer vorgesehen. Welche Art von Token Sie verwenden – Einmal- oder Sitzungstoken – hängt davon ab, welche Art von Interaktionen Ihre Webanwendung mit einem Google-Dienst haben wird. Ein Einmal-Token kann beispielsweise ausreichen, wenn die Interaktion ein einmaliges oder seltenes Ereignis ist.

    Wenn Sie Sitzungstokens abrufen und regelmäßig für den Zugriff auf den Google-Dienst verwenden, muss Ihre Webanwendung die Tokenspeicherung verwalten, einschließlich der Nachverfolgung des Nutzers und des Google-Dienstes, für den das Token gültig ist. Google-Konten sind nicht für die Verwaltung einer großen Anzahl von Tokens eingerichtet. Tatsächlich sind nicht mehr als zehn gültige Tokens (pro Nutzer, pro Webanwendung) gleichzeitig zulässig. Diese Einschränkung ermöglicht es einer Webanwendung, bei Bedarf mehrere Tokens für verschiedene Dienste zu erhalten. Es wird jedoch nicht unterstützt, jedes Mal ein neues Token abzurufen, wenn die Webanwendung auf einen Google-Dienst zugreifen muss. Wenn Sie Sitzungstokens speichern, sollten Sie sie genauso sicher behandeln wie alle anderen sensiblen Informationen, die auf dem Server gespeichert sind.

    Alternativ können Sie auch regelmäßig neue Tokens abrufen, sofern Sie einen Mechanismus zum Widerrufen von Tokens einrichten. Ihre Anwendung muss das vorhandene Token widerrufen, bevor sie ein anderes anfordern kann. In diesem Fall müsste sich der Nutzer jedes Mal anmelden und Zugriff gewähren, wenn ein neues Token angefordert wird.

  3. Ermitteln Sie den Bereich, der für den Zugriff auf den Google-Dienst erforderlich ist.

    Jeder Google-Dienst legt fest, wie viel und welche Art von Zugriff er zulässt. Dieser Zugriff wird als Bereichswert ausgedrückt. Der Bereich eines Dienstes kann eine einfache URL sein, die den gesamten Dienst identifiziert, oder er kann einen eingeschränkteren Zugriff angeben. Einige Dienste schränken den Zugriff stark ein, z. B. durch die Beschränkung auf den schreibgeschützten Zugriff auf begrenzte Informationen. Die zulässigen Bereiche für den Google-Dienst, auf den Sie zugreifen möchten, finden Sie in der Dokumentation zu diesem Dienst. Sie sollten das Token mit dem geringstmöglichen Umfang anfordern. Wenn Sie beispielsweise auf die Atom-Feed-Funktion von Gmail zugreifen möchten, verwenden Sie den Bereich „http://www.google.com/calendar/feeds/“ und nicht „http://www.google.com/calendar/“. Google-Dienste sind bei Anfragen mit großem Umfang viel restriktiver.

  4. Richten Sie einen Mechanismus ein, um ein Autorisierungstoken anzufordern und zu empfangen.

    Der Mechanismus muss einen wohlgeformten AuthSubRequest-Aufruf generieren, einschließlich der Angabe der entsprechenden next- und scope-URL-Werte (die in Schritt 3 ermittelt wurden). Wenn Sie sichere Tokens verwenden und/oder Sitzungstokens verwalten, muss die Anfrage auch Werte für diese Variablen enthalten.

    Die nächste URL kann Suchparameter enthalten. Wenn Sie beispielsweise mehrere Sprachen unterstützen, fügen Sie einen Abfrageparameter ein, der die Version der Webanwendung angibt, die der Nutzer aufruft. Ein next-Wert von http://www.yoursite.com/Retrievetoken?Lang=de würde zur Weiterleitung http://www.yoursite.com/Retrievetoken?Lang=de&token=DQAADKEDE führen. Durch das Parsen des Tokens und des Lang-Parameters wird sichergestellt, dass der Nutzer zur richtigen Version der Website zurückgeleitet wird.

    Unter bestimmten Umständen kann die Verwendung des Parameters hd dazu beitragen, die Nutzerfreundlichkeit zu verbessern, wenn Nutzer auf der Google-Konten-Website aufgefordert werden, Zugriff zu gewähren. In den meisten Fällen müssen sie sich dazu nur in ihrem Konto anmelden und auswählen, ob sie Zugriff gewähren möchten. Nutzer mit mehreren Google-Konten (ein reguläres Gmail-Konto und/oder ein oder mehrere gehostete Google Apps-Konten) müssen jedoch möglicherweise das zusätzliche Verfahren für die „universelle Anmeldung“ durchlaufen, um anzugeben, auf welches Konto sie zugreifen möchten. Wenn Ihre Anwendung für eine bestimmte verwaltete Domain entwickelt wurde, können Sie diese zusätzlichen Schritte vermeiden, indem Sie mit diesem Parameter die Domain angeben. Sie können auch den Parameter hd verwenden, wenn Ihre Anwendung auf Dienste zugreift, die nicht für gehostete Konten verfügbar sind. Wenn Sie den Wert auf „default“ festlegen, wird die Autorisierung auf reguläre Konten beschränkt. Wenn der Wert hd festgelegt ist, wählt Google automatisch das richtige Konto für die Autorisierung aus.

    Der Tokenmechanismus muss so ausgestattet sein, dass er die von Google empfangene Weiterleitung, die das Einmal-Token enthält, parsen und entsprechende Maßnahmen ergreifen kann. Da Autorisierungstokens nutzerspezifisch sind, muss Ihre Anwendung ein Token mit dem entsprechenden Nutzer verknüpfen können. Die bevorzugte Option besteht darin, dem Nutzer ein Cookie auszustellen, bevor die Tokenanfrage gestellt wird. Wenn Google den Nutzer dann mit einem angehängten Token zurück zu Ihrer Website weiterleitet, kann Ihre Anwendung das Cookie lesen und das Token der richtigen Nutzer-ID zuordnen.

  5. Richten Sie Mechanismen ein, um Sitzungstokens anzufordern und sie gegebenenfalls zu speichern oder zu widerrufen.

    Je nachdem, welche Entscheidungen zur Tokenverwaltung Sie in Schritt 2 getroffen haben, müssen Sie möglicherweise Mechanismen zum Abrufen und Widerrufen von Sitzungstokens (AuthSubSessionToken und AuthSubRevokeToken) erstellen. Verwenden Sie zum Testen von Sitzungs- und Widerrufsmechanismen AuthSubTokenInfo, um festzustellen, ob ein bestimmtes Token gültig ist. Wenn Tokens gespeichert werden, muss die Anwendung sowohl die Nutzer-ID als auch den vom Token abgedeckten Dienst (Bereich) erfassen.

  6. Richten Sie einen Mechanismus ein, um Zugriff auf einen Google-Dienst anzufordern.

    Informationen zum richtigen Anfrageformat finden Sie in der Dokumentation des Google-Dienstes. Alle Anfragen an einen Google-Dienst müssen ein gültiges Autorisierungstoken enthalten. Im Allgemeinen erfolgt eine Anfrage an einen Google-Dienst in Form eines HTTP-GET (oder POST, wenn neue Daten geschrieben werden), wobei das Token im Anfrageheader referenziert wird.

    Der Anfrageheader sollte so aussehen:

    Authorization: AuthSub token="token"

    Dabei ist token das Autorisierungstoken (Einmal- oder Sitzungstoken), das Sie von Google als Antwort auf eine AuthSub-Anfrage erhalten haben. Wenn das Token sicher ist, muss es mit einer digitalen Signatur versehen sein. Eine Anleitung und Beispiele finden Sie unter Anfragen signieren.

    Das folgende Beispiel zeigt einen Anfrageheader für einen Aufruf des Google Kalender-Feeddienstes. Diese Anfrage enthält ein nicht sicheres Token: 

    GET /calendar/feeds/default/private/full HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: AuthSub token="GD32CMCL25aZ-v____8B"
User-Agent: Java/1.5.0_06
Host: www.google.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

Weitere Informationen zu AuthSub

Informationen zu AuthSub, einschließlich der Registrierung Ihrer Anwendung bei Google und einer detaillierten Erklärung zum Tauschen eines Einmal-Tokens gegen ein Sitzungstoken, finden Sie in den folgenden zusätzlichen Ressourcen:

Nach oben

ClientLogin zur Autorisierung verwenden

ClientLogin ist eine proprietäre Autorisierungs-API von Google, die für die meisten Google APIs als Alternative zu OAuth verfügbar ist. Sie sollten ClientLogin nach Möglichkeit nicht verwenden. Wenn Sie bereits Anwendungen haben, die ClientLogin verwenden, sollten Sie zu OAuth oder zum Hybridprotokoll migrieren.

Authentifizierung für installierte Anwendungen: ClientLogin

Mit ClientLogin können sich Ihre Nutzer über Ihre Anwendung in ihrem Google-Konto anmelden. Die Anwendung kontaktiert dann Google mit den Anmeldedaten und fordert Zugriff auf eine bestimmte Google Data API an. Nachdem die Anmeldedaten erfolgreich authentifiziert wurden, gibt Google ein Token zurück, auf das Ihre Anwendung jedes Mal verweist, wenn sie Zugriff auf das Konto des Nutzers anfordert, z. B. um Daten abzurufen oder zu posten. Das Token bleibt für einen bestimmten Zeitraum gültig, der vom jeweiligen Google-Dienst abhängt.

Hinweis: Die Google Data APIs-Clientbibliotheken enthalten Methoden, mit denen Sie ClientLogin in Ihren installierten Anwendungen verwenden können. Es gibt Methoden zum Abrufen eines Authentifizierungstokens, zum Verarbeiten von CAPTCHA-Abfragen, zum Abrufen des Authentifizierungstokens für die spätere Verwendung und zum Senden des richtigen Authorization-Headers mit jeder Anfrage. Wenn Sie mit einer der Bibliotheken arbeiten, lesen Sie den Abschnitt ClientLogin mit den Google Data APIs-Clientbibliotheken verwenden.

Der ClientLogin-Autorisierungsprozess

Die Autorisierung mit ClientLogin umfasst eine Reihe von Interaktionen zwischen drei Einheiten: der installierten Anwendung, Google-Diensten und dem Nutzer. Das folgende Diagramm veranschaulicht die Sequenz:

Autorisierungsprozess

  1. Wenn die Drittanbieteranwendung auf einen Google-Dienst eines Nutzers zugreifen muss, ruft sie den Anmeldenamen und das Passwort des Nutzers ab.
  2. Die Drittanbieteranwendung führt dann einen ClientLogin-Aufruf an den Autorisierungsdienst von Google aus.
  3. Wenn der Google-Autorisierungsdienst feststellt, dass eine zusätzliche Überprüfung erforderlich ist, wird eine Fehlerantwort mit einem CAPTCHA-Token und einer CAPTCHA-Aufgabe in Form einer URL für ein CAPTCHA-Bild zurückgegeben.
  4. Wenn eine CAPTCHA-Aufgabe empfangen wird, zeigt die Drittanbieteranwendung das CAPTCHA-Bild für den Nutzer an und fordert ihn auf, eine Antwort zu geben.
  5. Auf Aufforderung gibt der Nutzer eine Antwort auf die CAPTCHA-Aufgabe ein.
  6. Die Drittanbieteranwendung führt einen neuen ClientLogin-Aufruf aus, der diesmal die CAPTCHA-Antwort und das Token (das mit der Fehlerantwort empfangen wurde) enthält.
  7. Bei einem erfolgreichen Anmeldeversuch (mit oder ohne CAPTCHA-Herausforderung) gibt der Google-Autorisierungsdienst ein Token an die Anwendung zurück.
  8. Die Anwendung kontaktiert den Google-Dienst mit einer Anfrage für den Datenzugriff und verweist auf das Token, das vom Google-Autorisierungsdienst empfangen wurde.
  9. Wenn der Google-Dienst das Token erkennt, gewährt er den angeforderten Datenzugriff.

ClientLogin verwenden

Über diese Schnittstelle können Sie in Ihrer installierten Anwendung programmatisch auf das Google-Konto eines Nutzers zugreifen. Nachdem Sie die Anmeldedaten des Nutzers erfasst haben, rufen Sie ClientLogin auf, um Zugriff auf das Konto des Nutzers anzufordern. Nachdem die Anmeldedaten erfolgreich authentifiziert wurden, gibt Google ein Token zurück, auf das Ihre Anwendung jedes Mal verweist, wenn sie Zugriff auf das Konto des Nutzers anfordert. Das Token bleibt für einen bestimmten Zeitraum gültig, der vom jeweiligen Google-Dienst abhängt.

Wenn Sie ClientLogin in Ihre Anwendung einbinden möchten, müssen Sie die folgenden Aufgaben ausführen:

  1. Erstellen Sie ein UI-Element, um Anmeldedaten vom Nutzer zu erfassen.

    In der Benutzeroberfläche müssen ein Nutzername (E-Mail-Adresse einschließlich Domain) und ein Passwort abgefragt werden. Die Benutzeroberfläche muss auch in der Lage sein, ein CAPTCHA-Bild über die von Google empfangene URL anzuzeigen, falls erforderlich, und eine richtige Antwort vom Nutzer anzufordern. Im Idealfall enthält Ihre Benutzeroberfläche einen Link zur Anmeldeseite für Google-Konten (https://www.google.com/accounts/Login), falls der Nutzer ein neues Konto erstellen oder andere Kontoverwaltungsaufgaben ausführen muss.

  2. Schreiben Sie Code, um eine wohlgeformte HTTPS-POST-Anfrage ClientLogin zu generieren und zu übertragen.

    Dieser Code muss Logik für die Verarbeitung einer CAPTCHA-Herausforderung enthalten und sowohl den Parameter logintoken als auch den Parameter logincaptcha umfassen. Die Anwendung sollte auch erkennen können, wenn der Nutzer erforderliche Informationen weglässt oder nach einem fehlgeschlagenen Login falsche Daten wiederholt, und eine Fehlermeldung anzeigen, ohne eine überflüssige Anfrage zu senden.

  3. Antworten von Google verarbeiten

    Es gibt vier mögliche Antworten auf eine Anmeldeanfrage:

    • Erfolg (HTTP 200)
    • Fehler (HTTP 403) mit einem erklärenden Fehlercode
    • Ungültige Anfrage, die in der Regel auf eine falsch formatierte Anfrage zurückzuführen ist
    • Fehler bei einer CAPTCHA-Aufgabe

    Eine Erfolgsantwort enthält ein Autorisierungstoken mit dem Label „Auth“. Dieses Token muss in allen nachfolgenden Anfragen an den Google-Dienst für dieses Konto enthalten sein. Autorisierungstokens sollten sorgfältig geschützt und nicht an andere Anwendungen weitergegeben werden, da sie den Zugriff auf das Konto des Nutzers ermöglichen. Das Zeitlimit für das Token hängt davon ab, von welchem Dienst es ausgestellt wurde.

    Eine Fehlerantwort enthält einen oder mehrere Fehlercodes und eine URL mit der Fehlermeldung, die dem Nutzer angezeigt werden kann. ClientLogin unterscheidet nicht zwischen einem Fehler aufgrund eines falschen Passworts und einem Fehler aufgrund eines unbekannten Nutzernamens (z. B. wenn der Nutzer noch kein Konto registriert hat). Ihre Anwendung muss alle möglichen Fehlermeldungen angemessen verarbeiten.

    Eine Fehlerantwort mit einer CAPTCHA-Aufforderung bedeutet, dass Google aus irgendeinem Grund entschieden hat, dass zusätzliche Sicherheitsmaßnahmen ergriffen werden sollten. Diese Antwort enthält eine CAPTCHA-Bild-URL und ein Token, das die spezifische CAPTCHA-Aufgabe darstellt.

  4. Eine CAPTCHA-Abfrage von Google bearbeiten

    Um die Aufgabe zu bearbeiten, muss die Anwendung das CAPTCHA-Bild anzeigen und den Nutzer um eine Antwort bitten. Wenn Sie das CAPTCHA-Bild anzeigen möchten, verwenden Sie den Wert von CaptchaUrl, der mit der Fehlerantwort zurückgegeben wird, und stellen Sie ihm die Google-Konten-URL voran: „http://www.google.com/accounts/“. Sobald der Nutzer eine Antwort gegeben hat, sollte die Anwendung die Anmeldeanfrage noch einmal senden. Diesmal sollte sie das CAPTCHA-Token (logintoken) und die Antwort des Nutzers (logincaptcha) enthalten. Google validiert die Antwort des Nutzers, bevor der Zugriff auf das Konto autorisiert wird.

    Es gibt eine Alternative für Entwickler, die die Prozesse zum Abrufen und Übertragen einer CAPTCHA-Antwort eines Nutzers nicht verwalten möchten. Als Reaktion auf eine CAPTCHA-Aufgabe kann die Anwendung den Nutzer auf die von Google gehostete Seite „https://www.google.com/accounts/DisplayUnlockCaptcha“ weiterleiten. Sobald der Nutzer die Challenge erfolgreich beantwortet hat, vertraut der Google-Server dem verwendeten Computer. Die Anwendung kann dann die ursprüngliche Anmeldeanfrage noch einmal senden, um das Autorisierungstoken zu erhalten.

    5. Hinweis:Google validiert den Anmeldeversuch nicht, bevor eine CAPTCHA-Herausforderung ausgegeben wird. Das bedeutet, dass ein Anmeldeversuch auch nach einer CAPTCHA-Aufgabe fehlschlagen kann.

* CAPTCHA ist eine Marke der Carnegie Mellon University.

Nach oben

Authentifizierung für Gadgets

OAuth-Proxy

Wenn Sie ein Gadget mit der Standard-Gadgets API erstellen, können Sie eine Funktion der Gadget-Plattform namens OAuth-Proxy nutzen, um auf die Google Data APIs zuzugreifen. OAuth (siehe oben) ist ein Authentifizierungsstandard, mit dem Nutzer auf ihre privaten Daten in einem Gadget-Hostingdienst wie iGoogle, MySpace oder Orkut zugreifen oder ihre Daten für eine andere Website oder ein anderes Gadget freigeben können. Der OAuth-Proxy soll die Entwicklung für Gadget-Entwickler vereinfachen, indem viele der Authentifizierungsdetails von OAuth ausgeblendet werden. Der Proxy basiert auf einem Open-Source-Projekt namens Shindig, das eine Implementierung der Gadget-Spezifikation ist.

Hinweis: Der OAuth-Proxy wird nur für Gadgets unterstützt, die die gadgets.*-API verwenden und in OpenSocial-Containern ausgeführt werden. Sie wird für die Legacy Gadgets API nicht unterstützt.

Authentifizierungsvorgang

Ihr Gadget muss ein OAuth-Token abrufen, bevor es auf die Daten eines Nutzers zugreifen kann. Der OAuth-Proxy verwaltet den Authentifizierungsablauf für Sie. Wenn ein Nutzer Ihr Gadget zum ersten Mal installiert, läuft der folgende Prozess ab:

  1. Ihr Gadget wird zum ersten Mal geladen und versucht, mit einer der Google Data APIs auf die Daten des Nutzers zuzugreifen.
  2. Die Anfrage schlägt fehl, weil der Nutzer keinen Zugriff gewährt hat. Das Antwortobjekt enthält eine URL (in response.oauthApprovalUrl) für die OAuth-Genehmigungsseite. Ihr Gadget sollte eine Methode zum Öffnen eines neuen Fensters mit dieser URL bieten.
  3. Auf der Genehmigungsseite kann der Nutzer den Zugriff auf Ihr Gadget gewähren oder verweigern. Im Erfolgsfall wird der Nutzer zur Seite oauth_callback weitergeleitet, die Sie angegeben haben. Für eine optimale Nutzererfahrung empfehlen wir, http://oauth.gmodules.com/gadgets/oauthcallback zu verwenden.
  4. Als Nächstes schließt der Nutzer das Pop-up-Fenster. Um Ihr Gadget darüber zu informieren, dass der Nutzer die Genehmigung erteilt hat, können Sie einen Pop-up-Handler verwenden, um das Schließen des Genehmigungsfensters zu erkennen. Alternativ kann Ihr Gadget einen Link (z.B. Ich habe den Zugriff genehmigt) anzeigen, auf den der Nutzer klicken kann, nachdem dieses Fenster geschlossen wurde.
  5. Ihr Gadget versucht, ein zweites Mal auf die Google Data API zuzugreifen, indem es die Daten des Nutzers noch einmal anfordert. Dieser Versuch ist erfolgreich.
  6. Ihr Gadget ist authentifiziert und kann normal verwendet werden.

Gadget einrichten

Wenn Sie auf eine oder mehrere Google Data APIs zugreifen möchten, müssen Sie Ihrem Gadget zuerst mitteilen, dass OAuth als Authentifizierungsmethode verwendet werden soll. Fügen Sie im Abschnitt <ModulePrefs> des XML-Codes Ihres Gadgets ein <OAuth>-Element hinzu:

<ModulePrefs>
...
<OAuth>
  <Service name="google">
    <Access url="https://www.google.com/accounts/OAuthGetAccessToken" method="GET" />
    <Request url="https://www.google.com/accounts/OAuthGetRequestToken?
                  scope=http://www.blogger.com/feeds/%20http://www.google.com/calendar/feeds/" method="GET" />
    <Authorization url="https://www.google.com/accounts/OAuthAuthorizeToken?
                        oauth_callback=http://oauth.gmodules.com/gadgets/oauthcallback" />
  </Service>
</OAuth>
...
</ModulePrefs>

Ändern Sie in diesem Abschnitt nur die folgenden Abfrageparameter:

scope
Ein erforderlicher Parameter in der Anfrage-URL. Ihr Gadget kann auf Daten aus den scope zugreifen, die in diesem Parameter verwendet werden. In diesem Beispiel kann das Gadget auf Blogger- und Kalenderdaten zugreifen. Ein Gadget kann Daten für einen oder mehrere Bereiche anfordern, wie in diesem Beispiel.
oauth_callback
Ein optionaler Parameter in der Autorisierungs-URL. Die OAuth-Genehmigungsseite leitet den Nutzer an diese URL weiter, nachdem er den Zugriff auf Daten genehmigt hat. Sie sollten diesen Parameter auf http://oauth.gmodules.com/gadgets/oauthcallback festlegen, um Nutzern beim Installieren Ihres Gadgets eine optimale Nutzererfahrung zu bieten. Auf dieser Seite finden Sie ein JavaScript-Snippet, mit dem das Pop-up-Fenster automatisch geschlossen wird. Alternativ können Sie diesen Parameter auf Ihre eigene „genehmigte“ Seite verweisen lassen oder ihn einfach leer lassen.

Auf einen authentifizierten Google Data API-Feed zugreifen

Nachdem Ihr Gadget den Nutzer authentifiziert hat, ist der Zugriff auf eine Google Data API mit der Google Data APIs JavaScript-Clientbibliothek ganz einfach. Informationen zur Verwendung der Bibliothek im OAuth-Proxy finden Sie unter JavaScript-Clientbibliothek verwenden.

Weitere Informationen zu Gadgets

Vollständige Informationen zum Erstellen von Google Data API-Gadgets, einschließlich Details zum OAuth-Proxy, einem Artikel zum Einstieg und der gadgets.*-Spezifikation, finden Sie in den folgenden zusätzlichen Ressourcen:

Nach oben