Authentifizierung und Autorisierung im Google-Datenprotokoll

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

Anwendungen von Drittanbietern erfordern häufig einen eingeschränkten Zugriff auf das Google-Konto eines Nutzers für bestimmte Aktivitäten. Damit die Nutzerdaten nicht missbraucht werden, müssen alle Zugriffsanfragen vom Kontoinhaber genehmigt werden. Die Zugriffssteuerung umfasst zwei Komponenten: Authentifizierung und Autorisierung.

Mit Authentifizierungsdiensten können sich Nutzer über ein Google-Konto in Ihrer Anwendung anmelden.

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

Authentifizierungs- und Autorisierungsdienste werden häufig zusammenfassend als auth bezeichnet.

Durch die Authentifizierung und Autorisierung für Google APIs erhalten Anwendungen von Drittanbietern eingeschränkten Zugriff auf das Google-Konto eines Nutzers für bestimmte Aktivitäten. In diesem Dokument werden die verfügbaren Authentifizierungsmechanismen und die jeweiligen Funktionen für Ihre Anwendung beschrieben.

  • Google Log-in bietet Nutzern eine einfache Möglichkeit, sich mit ihren Google-Anmeldedaten auf Ihrer Website anzumelden. Es umfasst eine Reihe von Tools, die sich leicht in verschiedene Geräte einbinden lassen.
  • OAuth 2.0 ist ein Autorisierungsprotokoll für alle Google APIs. OAuth 2.0 nutzt SSL zur Sicherheit, sodass Ihre Anwendung keine kryptografische Signierung direkt durchführen muss. 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) müssen sich die Nutzer mit ihren Google-Konten anmelden. Dies ist ein Ersatz für OpenID. OpenID-Nutzer sollten planen, sich mit OAuth 2.0 zu Login zu migrieren.

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

Hinweis: Dieses Dokument bietet eine Übersicht über jede Authentifizierungsmethode. Ausführliche Informationen zu den einzelnen Methoden finden Sie in der Dokumentation zur Google Account Authentication API.

Weitere Informationen zur Verwendung der Google Accounts APIs finden Sie in der Google Accounts API-Gruppe.

OAuth – Autorisierung für Webanwendungen und installierte Anwendungen

Viele Google-Dienste ermöglichen Drittanbieterzugriff auf von Nutzern erstellte Daten, z. B. Kalender- oder Dokumentdaten, sofern der Zugriff vom Nutzer autorisiert wurde. Mit diesem Feature können Nutzer Daten für verschiedene Zwecke zwischen ihren Google-Anwendungen und Anwendungen von Drittanbietern austauschen und austauschen.

Google unterstützt zwei Versionen von OAuth, um autorisierten Zugriff auf die Google-Daten eines Nutzers zu erhalten: 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 und 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. Ausführliche Informationen und Beispiele für die Implementierung von OAuth 2.0 mit Google findest du 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 Google-Implementierung der OAuth API nutzen. Ausführliche Informationen zum Implementieren von OAuth für webbasierte Anwendungen, einschließlich Beispielen, finden Sie in der Anleitung OAuth für Webanwendungen oder in der Übersicht in diesem Dokument.

OAuth 1.0 für installierte Anwendungen

Anwendungen, die auf den Computern und Mobilgeräten der Nutzer installiert sind, können mit OAuth den Zugriff auf Daten autorisieren, die mit einem Google-Konto verknüpft sind. Umfassende Informationen zur Implementierung von OAuth für installierte Anwendungen finden Sie in der Anleitung OAuth für installierte Anwendungen oder in der Übersicht in diesem Dokument.

OAuth mit Webanwendungen verwenden

Alle Google Data APIs unterstützen OAuth, einen offenen Standard zur Autorisierung von Daten in Webanwendungen. Alle Webanwendungen, die OAuth-Anfragen senden, 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 bieten Methoden, die Sie bei der Verwendung von OAuth in Ihrer Webanwendung unterstützen. Insbesondere gibt es Methoden zum Erstellen des Anfrage-Tokens, zum Autorisieren des Anfrage-Tokens und zum Austauschen des autorisierten Anfrage-Tokens gegen ein Zugriffstoken. Die Bibliotheken verarbeiten auch die erforderlichen Signaturalgorithmen, wenn Sie Anfragen an einen Google Data-Dienst stellen. Ausführliche Beispiele zur Verwendung von OAuth mit den Google Data API-Clientbibliotheken finden Sie unter OAuth mit den Google Data APIs-Clientbibliotheken verwenden.

OAuth-Autorisierung

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

Der Prozess sieht so aus:

  1. Ihre Anwendung fordert Zugriff an und erhält ein nicht autorisiertes Anfragetoken vom Google-Autorisierungsserver.
  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 Anfrage-Token gegen ein Zugriffstoken aus.
  5. Sie verwenden das Zugriffstoken, um Daten von den Zugriffsservern von Google anzufordern.

Wenn Ihre Anwendung den Zugriff auf die Daten eines Nutzers anfordert, sendet Google ein nicht autorisiertes Anfragetoken an Ihre Anwendung.

Wenn der Nutzer nicht bereits 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 App Zugriff anfordert.

Wenn der Nutzer die Zugriffsanforderung Ihrer Anwendung genehmigt, gibt Google ein autorisiertes Anforderungstoken aus. Jedes Anfragetoken ist nur eine Stunde lang gültig. Nur ein autorisiertes Anfrage-Token kann gegen ein Zugriffstoken ausgetauscht werden. Dieser Austausch kann nur einmal pro autorisierter Anfrage-Token erfolgen.

Zugriffstokens sind standardmäßig langlebig. Jedes Zugriffstoken ist spezifisch für das Nutzerkonto, das in der ursprünglichen Autorisierungsanfrage angegeben war, und gewährt nur Zugriff auf die in der Anfrage angegebenen Dienste. Ihre Anwendung sollte das Zugriffstoken sicher speichern, da sie für den gesamten Zugriff auf die Daten eines Nutzers erforderlich ist.

Vorbereitung auf OAuth

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

Entscheiden, ob Sie Ihre Webanwendung registrieren möchten

Wenn Sie Ihren Nutzern zusätzliche Sicherheit für ihre Daten geben möchten, 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 zur gewünschten Google Data API können Sie nachlesen, ob diese API nur mit registrierten Anwendungen funktioniert.

Ihre Anwendung muss jede zugehörige OAuth-Anfrage signieren. Wenn Sie zum Signieren Ihrer Anfragen eine RSA-SHA1-Signatur verwenden, müssen Sie im Rahmen des Registrierungsprozesses ein Sicherheitszertifikat hochladen.

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

Weitere Informationen zur Registrierung finden Sie unter Registrierung für Webanwendungen.

Umfang der Daten festlegen, auf die Ihre Anwendung zugreift

Jeder Google-Dienst legt Limits für den Zugriff fest, der über die Google Data APIs möglich ist. Dieser Zugriff wird als Umfangswert ausgedrückt. Einige Dienste bieten eine Vielzahl von Bereichswerten, damit Nutzer auswählen können, welche Anwendungen Zugriff auf welche Daten haben sollen. Informationen zu den verfügbaren Bereichswerten für den Google-Dienst, auf den Sie zugreifen möchten, finden Sie in der Dokumentation für diesen Dienst.

Im Allgemeinen sollten Sie ein Token für den engsten Umfang anfordern, der die benötigten Daten enthält. 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.

Einen Mechanismus zum Verwalten von OAuth-Tokens einrichten

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

Ihre Anwendung sollte den Tokenspeicher sicher verwalten und den Google-Dienst verfolgen, für den die einzelnen Tokens gültig sind. Wenn Sie Zugriff auf mehr als einen Google-Dienst benötigen, können Sie mehrere Zugriffstokens anfordern. Es können jedoch nicht mehr als 10 Zugriffstokens pro Nutzer und Anwendung gleichzeitig ausstehen.

Wenn Ihre Anwendung mehrere Nutzerkonten unterstützt, müssen Sie verfolgen, mit welchem Konto die einzelnen Tokens verknüpft sind. Jedes OAuth-Token ist spezifisch für den Nutzer, der den Zugriff autorisiert hat. Ihre Anwendung muss ein Token mit dem richtigen Nutzer verknüpfen können. Eine Möglichkeit, dies zu verwalten, besteht darin, dem Nutzer ein Cookie zu senden, bevor die Tokenanfrage gesendet wird. Nachdem der Nutzer Zugriff auf die angeforderten Daten gewährt hat, sendet Google ein autorisiertes Anfragetoken und leitet den Nutzer an Ihre Anwendung weiter. Sie können dann das Cookie Ihrer Anwendung verwenden, um das Token mit dem richtigen Nutzer zu verknüpfen.

Einen Mechanismus einrichten, um Zugriff auf einen Google-Dienst anzufordern

Jede Anfrage an einen Google-Dienst muss signiert sein und ein gültiges OAuth-Zugriffstoken enthalten. Im Allgemeinen erfolgt jede Anfrage in Form einer HTTP-GET-Anfrage, wobei das Zugriffstoken und die Signatur im Header enthalten sind. Anfragen, die neue Daten schreiben, sollten HTTP POST verwenden.

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 die beiden Prozesse mit dem Hybridprotokoll kombinieren. Mit OpenID+OAuth werden die Schritte zum Abrufen und Autorisieren eines Anfragetokens als Teil der OpenID-Anfrage mit OAuth-Erweiterungen verarbeitet. 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 Anfragetoken. Nachdem das Token empfangen wurde, tauschen Sie es mit OAuthGetAccessToken gegen ein Zugriffstoken aus.

Mit OAuth-Tokens arbeiten

Ihre Anwendung muss korrekt signierte, signierte Tokenanfrageaufrufe generieren und die Antworten in der folgenden Reihenfolge verarbeiten, um OAuth zu verwenden:

  1. Nicht autorisiertes Anfragetoken abrufen (OAuthGetRequestToken)
  2. Autorisierungstoken autorisieren (OAuthAuthorizeToken)
  3. Tauschen Sie das autorisierte Anfrage-Token gegen ein Zugriffstoken aus (OAuthGetAccessToken).

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

Im OAuth Playground können Sie mit Autorisierungsanfragen und -empfang experimentieren.

Eine ausführliche 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 zu bestimmen, wohin Google den Nutzer nach der Autorisierung Ihrer Zugriffsanfrage weiterleitet. Die Callback-URL kann Suchparameter enthalten. Die Weiterleitung enthält dieselben Abfrageparameter sowie das autorisierte Anfragetoken, das Ihre Anwendung parsen muss.

Wenn du beispielsweise mehrere Sprachen unterstützt, kannst du einen Abfrageparameter angeben, der die Version der Anwendung identifiziert, die sich ein Nutzer ansieht. Der Wert oauth_callback für „http://www.yoursite.com/Retrievetoken?Lang=de“ führt zu der Weiterleitung „http://www.yoursite.com/Retrievetoken?Lang=de&oauth_token=DQAADKEDE“. Durch das Parsen des Tokens und des Sprachparameters wird sichergestellt, dass der Nutzer wieder zur richtigen Version der Website weitergeleitet wird.

Wenn der Parameter oauth_callback nicht angegeben ist, leitet Google den Nutzer nach der Autorisierung deiner 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.

Anwendung für Nutzer identifizieren

Google zeigt normalerweise den Namen einer Anwendung an, wenn vom Nutzer eine Einwilligung 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 vom Parameter oauth_callback bereitgestellt wird. Wenn keine Callback-URL angegeben wird, 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. Sie erhalten dann eine Nachricht, dass die Identität Ihrer Anwendung nicht bestätigt werden kann.

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

Arbeiten mit Google Apps-Domains

Wenn Ihre Anwendung für Nutzer in einer gehosteten Google-Konten-Domain entwickelt wurde, sollten Sie bei der Autorisierung eines Tokens den Parameter hd verwenden. 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 diesen zusätzlichen Ressourcen:

Nach oben

OAuth mit installierten Anwendungen verwenden

Alle Google Data APIs unterstützen OAuth, einen offenen Standard zur Autorisierung von Daten in Anwendungen. Installierte Anwendungen müssen nicht bei Google registriert sein, um OAuth zu verwenden.

OAuth-Autorisierung

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

Der Prozess sieht so aus:

  1. Ihre Anwendung fordert Zugriff an und erhält ein nicht autorisiertes Anfragetoken vom Google-Autorisierungsserver.
  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 Anfrage-Token gegen ein Zugriffstoken aus.
  5. Sie verwenden das Zugriffstoken, um Daten von den Zugriffsservern von Google anzufordern.

Wenn Ihre Anwendung den Zugriff auf die Daten eines Nutzers anfordert, sendet Google ein nicht autorisiertes Anfragetoken an Ihre Anwendung.

Wenn der Nutzer nicht bereits 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 App Zugriff anfordert.

Wenn der Nutzer die Zugriffsanforderung Ihrer Anwendung genehmigt, gibt Google ein autorisiertes Anforderungstoken aus. Jedes Anfragetoken ist nur eine Stunde lang gültig. Nur ein autorisiertes Anfrage-Token kann gegen ein Zugriffstoken ausgetauscht werden. Dieser Austausch kann nur einmal pro autorisierter Anfrage-Token erfolgen.

OAuth unterstützt installierte Anwendungen im nicht registrierten Modus. Da es verschiedene Methoden zum Abrufen eines autorisierten Anfrage-Tokens gibt, kann Ihre App eine Anwendung auch dann mit OAuth autorisieren, wenn das Gerät, auf dem sie installiert ist, keinen Webbrowser hat.

Zugriffstokens sind standardmäßig langlebig. Jedes Zugriffstoken ist spezifisch für das Nutzerkonto, das in der ursprünglichen Autorisierungsanfrage angegeben war, und gewährt nur Zugriff auf die in der Anfrage angegebenen Dienste. Ihre Anwendung sollte das Zugriffstoken sicher speichern, da sie für den gesamten Zugriff auf die Daten eines Nutzers erforderlich ist.

Vorbereitung auf OAuth

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

Umfang der Daten festlegen, auf die Ihre Anwendung zugreift

Jeder Google-Dienst legt Limits für den Zugriff fest, der über die Google Data APIs möglich ist. Dieser Zugriff wird als Umfangswert ausgedrückt. Einige Dienste bieten eine Vielzahl von Bereichswerten, damit Nutzer auswählen können, welche Anwendungen Zugriff auf welche Daten haben sollen. Informationen zu den verfügbaren Bereichswerten für den Google-Dienst, auf den Sie zugreifen möchten, finden Sie in der Dokumentation für diesen Dienst.

Im Allgemeinen sollten Sie ein Token für den engsten Umfang anfordern, der die benötigten Daten enthält. 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.

Einen Mechanismus zum Verwalten von OAuth-Tokens einrichten

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

Ihre Anwendung sollte den Tokenspeicher sicher verwalten und den Google-Dienst verfolgen, für den die einzelnen Tokens gültig sind.

Wenn Ihre Anwendung mehrere Nutzerkonten unterstützt, müssen Sie verfolgen, mit welchem Konto die einzelnen Tokens verknüpft sind.

Einen Mechanismus einrichten, um Zugriff auf einen Google-Dienst anzufordern

Jede Anfrage an einen Google-Dienst muss signiert sein und ein gültiges OAuth-Zugriffstoken enthalten. Im Allgemeinen erfolgt jede Anfrage in Form einer HTTP-GET-Anfrage, wobei das Zugriffstoken und die Signatur im Header enthalten sind. Anfragen, die neue Daten schreiben, sollten HTTP POST verwenden.

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

Mit OAuth-Tokens arbeiten

Ihre Anwendung muss korrekt signierte, signierte Tokenanfrageaufrufe generieren und die Antworten in der folgenden Reihenfolge verarbeiten, um OAuth zu verwenden:

  1. Nicht autorisiertes Anfragetoken abrufen (OAuthGetRequestToken)
  2. Autorisierungstoken autorisieren (OAuthAuthorizeToken)
  3. Tauschen Sie das autorisierte Anfrage-Token gegen ein Zugriffstoken aus (OAuthGetAccessToken).

Alle OAuth-Anfragen müssen signiert sein, unabhängig davon, ob Ihre Anwendung registriert ist. Weitere Informationen finden Sie unter OAuth-Anfragen signieren. Installierte Anwendungen sollten der Anleitung für eine nicht registrierte Anwendung folgen.

Im OAuth Playground können Sie mit Autorisierungsanfragen und -empfang experimentieren.

Eine ausführliche Dokumentation finden Sie in der OAuth API-Referenz.

Anwendung für Nutzer identifizieren

Google zeigt normalerweise den Namen einer Anwendung an, wenn vom Nutzer eine Einwilligung 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 vom Parameter oauth_callback bereitgestellt wird. Wenn keine Callback-URL angegeben wird, zeigt Google den String „anonymous“ an.

Hinweis:Wenn Sie den Parameter xoauth_displayname im OAuth Playground festlegen möchten, klicken Sie das Kästchen „Erweitert“ an, 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 Modus „Automatisch erkennen“ sollte für die meisten Anwendungen verwendet werden
  • Der Gerätemodus sollte für Anwendungen verwendet werden, die keinen vollwertigen Webbrowser starten können.
  • Der Entwicklungsmodus sollte nur in einer frühen Entwicklungsphase verwendet werden.

Modus „Automatisch erkennen“

Falls möglich, sollte deine Anwendung ein Browserfenster öffnen und eine OAuthAuthorizeToken-Anfrage zum Öffnen der Google-Seite stellen. Wenn Google das autorisierte Token zurückgibt, sollte die Anwendung dies erkennen und den Fokus wieder über den Webbrowser erlangen.

In diesem Modus musst du eine Callback-URL angeben, zu der der Nutzer weitergeleitet wird, nachdem er deine Zugriffsanfrage autorisiert hat. Diese URL muss als oauth_callback-Parameter der OAuthGetRequestToken-Anfrage und als verifier-Parameter der OAuthGetAccessToken-Anfrage angegeben werden.

Zur Verbesserung der Nutzererfahrung sollte Ihre Anwendung automatisch erkennen, wenn der Nutzer zu dieser URL weitergeleitet wird, sich sofort im Vordergrund anzeigen lassen und eine OAuthGetAccessToken-Anfrage senden, um den OAuth-Vorgang abzuschließen.

Weitere Informationen und Best Practices finden Sie unter Genehmigung automatisch erkennen.

Wenn deine Anwendung nicht automatisch erkennen kann, wann der Nutzer zur Callback-URL weitergeleitet wird, oder wenn sie nicht in den Vordergrund gelangen kann, sollte die Callback-URL eine Seite anzeigen, auf der erläutert wird, wie du deine Anwendung in den Vordergrund ziehst und die OAuthGetAccessToken-Anfrage von deiner Anwendung aus starten kannst.

Gerätemodus

Wenn die 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 Code, der von Google generiert und zur Website des Entwicklers weitergeleitet wird. Auf dieser Website sollte der Nutzer erfahren, wie er den Code in sein Gerät eingibt, um die Autorisierung abzuschließen.

Entwicklungsmodus

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

Wie im AutoDetect-Modus muss Ihre Anwendung einen Browser starten und der Nutzer muss Ihre Anfrage autorisieren. Statt jedoch eine Webseite für die Callback-URL zu erstellen, kannst du den Wert des oauth_callback-Parameters auf "oob" (out of band) setzen.

Nachdem der Nutzer deine Anfrage autorisiert hat, leitet Google den Nutzer zu einer Google-Kontoseite weiter, auf der eine Bestätigungsnummer angezeigt wird (siehe Beispiel).

Der Nutzer muss zu Ihrer Anwendung zurückkehren und die Bestätigungsnummer eingeben, bevor Sie eine OAuthGetAccessToken-Anfrage senden 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 diesen zusätzlichen Ressourcen:

Nach oben

AuthSub zur Autorisierung verwenden

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

Autorisierungsverfahren von AuthSub

Die Autorisierung mit AuthSub umfasst eine Abfolge von Interaktionen zwischen drei Entitäten: der Webanwendung, den Google-Diensten und dem Nutzer. Dieses Diagramm veranschaulicht die Sequenz:

Autorisierungsverfahren

  1. Wenn die Webanwendung auf den Google-Dienst eines Nutzers zugreifen muss, wird ein AuthSub-Aufruf an den Autorisierungs-Proxy-Dienst von Google gesendet.
  2. Der Autorisierungsdienst antwortet, indem er eine Seite für eine Zugriffsanfrage bereitstellt. Auf dieser von Google verwalteten Seite wird der Nutzer aufgefordert, 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 Zugriff auf die Webanwendung erhält oder verweigert. Wenn der Nutzer den Zugriff verweigert, wird er zu einer Google-Seite weitergeleitet und nicht zur Webanwendung.
  4. Wenn der Nutzer Zugriff gewährt, wird er vom Autorisierungsdienst zur Webanwendung zurückgeleitet. Die Weiterleitung enthält ein Autorisierungstoken, das nur 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 für den Nutzer als Agent zu fungieren.
  6. Wenn der Google-Dienst das Token erkennt, stellt er die angeforderten Daten bereit.

Mit AuthSub arbeiten

Für die Einbindung von AuthSub in Ihre Webanwendung sind folgende Schritte erforderlich:

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

    Registrierte Webanwendungen haben den Vorteil, dass sie von Google erkannt werden. Der Standard-Hinweis für Nutzer auf der Google-Anmeldeseite wird geändert oder weggelassen. Außerdem werden registrierte Webanwendungen anhand eines aussagekräftigen Namens und nicht nur der aufrufenden URL identifiziert. Beachten Sie, dass einige Google-Dienste nur eingeschränkten Zugriff auf nicht registrierte Webanwendungen gewähren. Wenn Sie sich registrieren, können Sie diesen automatisierten Registrierungsprozess nutzen.

    Bei der Registrierung können Sie auch ein Sicherheitszertifikat und Schlüssel angeben. Registrierte Webanwendungen, für die ein Zertifikat hinterlegt ist, können sichere Tokens zur Anforderung von Daten von einem Google-Dienst abrufen. Bei Bedarf können sie auch nicht sichere Tokens verwenden.

  2. Entscheiden Sie, welche Tokentypen verwendet und wie sie verwaltet werden sollen.

    Ein von Google erhaltenes Autorisierungstoken soll für alle zukünftigen Interaktionen mit dem angegebenen Google-Dienst für diesen Nutzer verwendet werden. Welche Art von Token Sie verwenden, hängt von der Art der Interaktionen mit Ihrer Webanwendung mit einem Google-Dienst ab. Ein einmaliges Token kann zum Beispiel ausreichend sein, wenn die Interaktion ein einmaliges oder seltenes Ereignis ist.

    Wenn Sie sich für das Abrufen von Sitzungstokens entscheiden und diese regelmäßig für den Zugriff auf den Google-Dienst verwenden, muss Ihre Webanwendung den Tokenspeicher verwalten und unter anderem den Nutzer und den Google-Dienst verfolgen, für den das Token gültig ist. Google-Konten sind nicht für die Verwaltung einer großen Anzahl von Tokens eingerichtet und lassen nicht mehr als zehn gültige Tokens (pro Nutzer und pro Webanwendung) gleichzeitig zu. Diese Einschränkung ermöglicht es einer Webanwendung, mehrere Tokens abzurufen, um verschiedene Dienste abzudecken. Sie unterstützt nicht das Abrufen eines neuen Tokens, wenn die Webanwendung auf einen Google-Dienst zugreifen muss. Wenn Sie Sitzungstokens speichern, sollten die Tokens genauso sicher behandelt werden wie alle anderen vertraulichen Informationen, die auf dem Server gespeichert sind.

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

  3. Legen Sie den Umfang fest, auf den der Google-Dienst zugreifen muss.

    Jeder Google-Dienst bestimmt, wie viel und welche Art von Zugriff er zulässt. Dieser Zugriff wird als Umfangswert ausgedrückt. Der Bereich eines Dienstes kann eine einfache URL sein, die den gesamten Dienst identifiziert, oder einen eingeschränkten Zugriff angeben. Einige Dienste schränken den Zugriff erheblich ein, z. B. den schreibgeschützten Zugriff auf eingeschränkte Informationen. Die zulässigen Bereiche für den Google-Dienst, auf den Sie zugreifen möchten, finden Sie in der Dokumentation für diesen Dienst. Fordern Sie das Token mit dem größtmöglichen Umfang an. Wenn Sie zum Beispiel auf die Atom-Feed-Funktion von Google Mail zugreifen möchten, verwenden Sie den Geltungsbereich "http://www.google.com/calendar/feeds/", nicht "http://www.google.com/calendar/". Google-Dienste sind durch umfangreiche Anfragen viel stärker eingeschränkt.

  4. Richten Sie ein Verfahren zum Anfordern und Empfangen eines Autorisierungstokens ein.

    Der Mechanismus muss einen wohlgeformten AuthSubRequest-Aufruf generieren, in dem die entsprechenden next- und scope-URL-Werte angegeben sind (wie in Schritt 3 bestimmt). 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 Suchparameter hinzu, der die Version der Webanwendung angibt, die sich der Nutzer ansieht. Ein next-Wert von http://www.yoursite.com/Retrievetoken?Lang=de würde zur Weiterleitung von 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 der Parameter hd dazu beitragen, die Benutzerfreundlichkeit zu optimieren, wenn die Nutzer aufgefordert werden, Zugriff auf der Website des Google-Kontos zu gewähren. In den meisten Fällen müssen Sie sich einfach in ihrem Konto anmelden und auswählen, ob Sie Zugriff gewähren möchten. Nutzer mit mehr als einem Google-Konto (ein reguläres Gmail-Konto und/oder ein oder mehrere gehostete Konten für Google Apps) müssen jedoch unter Umständen den zusätzlichen "universellen Log-in"-Vorgang ausführen, um zu ermitteln, 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 diesen Parameter zur Identifizierung der Domain verwenden. Sie können den Parameter hd auch verwenden, wenn Ihre Anwendung auf Dienste zugreift, die nicht für gehostete Konten verfügbar sind. Wenn Sie den Wert auf "Standard" setzen, 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 eingerichtet sein, dass er die von Google empfangene Weiterleitung, die das Einweg-Token enthält, parsen kann, und Maßnahmen ergreifen. Da Autorisierungstoken nutzerspezifisch sind, muss Ihre Anwendung ein Token mit dem Nutzer verknüpfen können. Die bevorzugte Option ist, ein Cookie an den Nutzer zu senden, bevor er eine Tokenanfrage stellt. Wenn Google den Nutzer dann mit einem angehängten Token zurück auf Ihre Website leitet, kann Ihre Anwendung das Cookie lesen und das Token mit der richtigen Nutzeridentifikation verknüpfen.

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

    Je nachdem, welche Token-Verwaltungsentscheidungen Sie in Schritt 2 getroffen haben, müssen Sie möglicherweise Mechanismen zum Abrufen und Widerrufen von Sitzungstokens (AuthSubSessionToken und AuthSubWiderrufToken) erstellen. Verwenden Sie zum Testen von Sitzungs- und Widerrufsmechanismen AuthSubTokenInfo, die angibt, ob ein bestimmtes Token gültig ist oder nicht. Beim Speichern von Tokens muss die Anwendung sowohl die Nutzer-ID als auch den vom Token abgedeckten Dienst (Umfang) erfassen.

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

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

    Der Anfrageheader sollte das folgende Format haben:

    Authorization: AuthSub token="token"

    Dabei ist token das Autorisierungs-Token (einmalige Verwendung oder Sitzung), das als Antwort auf eine AuthSub-Anfrage von Google empfangen wurde. 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 an den Google Kalender-Feeddienst. 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

Weitere Informationen zu AuthSub, einschließlich der Registrierung Ihrer Anwendung bei Google, und einer ausführlichen Erläuterung des Austauschs eines einmaligen Tokens durch ein Sitzungstoken finden Sie in diesen zusätzlichen Ressourcen:

Nach oben

ClientLogin zur Autorisierung verwenden

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

Authentifizierung für installierte Anwendungen: ClientLogin

ClientLogin ermöglicht es Nutzern, sich innerhalb Ihrer Anwendung in ihrem Google-Konto anzumelden. Die Anwendung kontaktiert dann Google mit den Anmeldedaten und fordert Zugriff auf eine bestimmte Google Data API an. Sobald die Anmeldedaten erfolgreich authentifiziert wurden, gibt Google ein Token zurück, auf das Ihre Anwendung immer dann zugreift, wenn sie Zugriff auf das Nutzerkonto anfordert, z. B. um Daten abzurufen oder zu posten. Das Token bleibt für einen festgelegten Zeitraum gültig, je nachdem, mit welchem Google-Dienst Sie arbeiten.

Hinweis: Die Google Data APIs-Clientbibliotheken bieten Methoden zur Verwendung von ClientLogin in Ihren installierten Anwendungen. Insbesondere gibt es Methoden, um ein Authentifizierungstoken zu erhalten, CAPTCHA-Herausforderungen zu verarbeiten, das Authentifizierungstoken für die spätere Verwendung abzurufen und mit jeder Anfrage den richtigen Authorization-Header zu senden. Wenn Sie mit einer der Bibliotheken arbeiten, finden Sie weitere Informationen unter ClientLogin mit den Google Data APIs-Clientbibliotheken verwenden.

Autorisierungsprozess für ClientLogin

Die Autorisierung mit ClientLogin beinhaltet eine Abfolge von Interaktionen zwischen drei Entitäten: der installierten Anwendung, Google-Diensten und dem Nutzer. Dieses Diagramm veranschaulicht die Sequenz:

Autorisierungsverfahren

  1. Wenn die Drittanbieteranwendung auf den Google-Dienst eines Nutzers zugreifen muss, ruft er den Anmeldenamen und das Passwort des Nutzers ab.
  2. Die Drittanbieteranwendung sendet dann einen ClientLogin-Aufruf an den Autorisierungsdienst von Google.
  3. Wenn der Google-Autorisierungsdienst eine zusätzliche Überprüfung erfordert, gibt er eine Fehlerantwort mit einem CAPTCHA-Token und einer Identitätsbestätigung in Form einer URL für ein CAPTCHA-Bild zurück.
  4. Wenn eine CAPTCHA-Eingabe empfangen wird, zeigt die Drittanbieteranwendung das CAPTCHA-Bild für den Nutzer an und fordert den Nutzer zu einer Antwort auf.
  5. Auf Anfrage kann der Nutzer eine Antwort auf die CAPTCHA-Abfrage senden.
  6. Die Drittanbieteranwendung führt einen neuen ClientLogin-Aufruf durch, einschließlich der CAPTCHA-Antwort und des Tokens (die mit der Fehlerantwort empfangen wurden).
  7. Bei einem erfolgreichen Anmeldeversuch (mit oder ohne CAPTCHA-Abfrage) 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 dabei auf das Token, das Sie vom Google-Autorisierungsdienst erhalten haben.
  9. Wenn der Google-Dienst das Token erkennt, stellt er den angeforderten Datenzugriff bereit.

ClientLogin verwenden

Über diese Schnittstelle in Ihrer installierten Anwendung können Sie programmatisch auf das Google-Konto eines Nutzers zugreifen. Nachdem Sie die Anmeldeinformationen 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 immer dann verweist, wenn sie Zugriff auf das Nutzerkonto anfordert. Das Token bleibt für einen bestimmten Zeitraum gültig, der vom jeweiligen Google-Dienst festgelegt wird.

Die Einbindung von ClientLogin in Ihre Anwendung erfordert folgende Aufgaben:

  1. Erstellen Sie ein UI-Element, um Anmeldedaten des Nutzers zu erfassen.

    In der Benutzeroberfläche muss ein Nutzername (E-Mail-Adresse mit Domain) und ein Passwort angefordert werden. Die Benutzeroberfläche sollte außerdem in der Lage sein, ein CAPTCHA-Bild mit der von Google erhaltenen URL anzuzeigen, falls diese erforderlich ist, und vom Nutzer eine korrekte Antwort anzufordern. Idealerweise enthält Ihre Benutzeroberfläche einen Link zur Anmeldeseite von Google-Konten ("https://www.google.com/accounts/Login"), wenn sich der Nutzer für ein neues Konto registrieren oder andere Wartungsarbeiten durchführen muss.

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

    Dieser Code muss Logik für die Verarbeitung einer CAPTCHA-Herausforderung sowie die Parameter logintoken und logincaptcha enthalten. Die Anwendung sollte außerdem in der Lage sein zu erkennen, wenn der Nutzer die erforderlichen Informationen auslässt oder nach einem Fehler bei der Anmeldung falsche Daten wiedergibt. Außerdem sollte ein Fehler angezeigt werden, ohne dass eine überflüssige Anfrage gesendet wird.

  3. Antworten von Google verarbeiten

    Es gibt vier mögliche Antworten auf eine Anmeldeanfrage:

    • Erfolgreich (HTTP 200)
    • Fehler (HTTP 403) mit einem Fehlercode
    • ungültige Anfrage, die sich in der Regel aus einer fehlerhaften Anfrage ergibt
    • Fehler bei einer CAPTCHA-Abfrage

    Eine Erfolgsantwort enthält ein Autorisierungstoken mit der Bezeichnung „Auth“. Dieses Token muss in allen nachfolgenden Anfragen an den Google-Dienst für dieses Konto enthalten sein. Autorisierungstokens sollten streng überwacht und nicht an andere Anwendungen weitergegeben werden, da sie den Zugriff auf das Konto des Nutzers darstellen. Das Zeitlimit für das Token hängt davon ab, welcher Dienst es ausgestellt hat.

    Eine Fehlerantwort enthält einen oder mehrere Fehlercodes und eine URL mit der Fehlermeldung, die dem Nutzer angezeigt werden kann. Bitte beachten Sie, dass ClientLogin nicht unterscheidet, ob ein Fehler aufgrund eines falschen Passworts oder ein Fehler aufgrund eines unbekannten Nutzernamens aufgetreten ist (z. B. wenn der Nutzer sich noch nicht für ein Konto registriert hat). Ihre Anwendung muss alle möglichen Fehlermeldungen verarbeiten können.

    Wenn im Rahmen einer CAPTCHA-Abfrage ein Fehler gemeldet wird, hat Google aus irgendeinem Grund zusätzliche Sicherheitsmaßnahmen ergriffen. Diese Antwort wird von einer CAPTCHA-Bild-URL und einem Token begleitet, das die spezifische CAPTCHA-Herausforderung repräsentiert.

  4. Behandeln Sie eine CAPTCHA-Herausforderung von Google.

    Zur Behebung des Problems muss die Anwendung das CAPTCHA-Bild anzeigen und eine Antwort vom Nutzer anfordern. Verwenden Sie zum Anzeigen des CAPTCHA-Bilds den Wert von CaptchaUrl, der mit der Fehlerantwort zurückgegeben wurde. Setzen Sie dabei die URL der Google-Konten: http://www.google.com/accounts/ voran. Sobald der Nutzer eine Antwort gegeben hat, sollte die Anwendung die Anmeldeanfrage noch einmal senden, einschließlich des CAPTCHA-Tokens (logintoken) und der Antwort des Nutzers (logincaptcha). Google validiert die Antwort des Nutzers, bevor der Zugriff auf das Konto autorisiert wird.

    Es gibt eine Alternative für Entwickler, die den Prozess zum Abrufen und Übertragen einer CAPTCHA-Antwort für Nutzer nicht verwalten möchten. Als Reaktion auf ein CAPTCHA kann die Anwendung den Nutzer zur von Google gehosteten Seite weiterleiten: https://www.google.com/accounts/DisplayUnlockCaptcha. Nachdem der Nutzer erfolgreich auf die Identitätsbestätigung reagiert hat, vertraut der Google-Server dem verwendeten Computer. Die Anwendung kann dann die ursprüngliche Anmeldeanfrage noch einmal senden, um das Autorisierungstoken abzurufen.

    5. Hinweis: Google überprüft den Anmeldeversuch erst, wenn eine CAPTCHA-Abfrage gesendet wird. Das bedeutet, dass ein Anmeldeversuch auch nach einer CAPTCHA-Abfrage fehlschlagen kann.

* CAPTCHA ist eine Marke der Carnegie Mellon University.

Nach oben

Authentifizierung für Gadgets

OAuth-Proxy

Wenn Sie ein Gadget mit der standardmäßigen Gadgets API erstellen, können Sie die Funktion „OAuth Proxy“ nutzen, um auf die Google Data APIs zuzugreifen. OAuth (oben beschrieben) ist ein Authentifizierungsstandard, mit dem Nutzer in einem Gadget-Hostingdienst wie iGoogle, MySpace oder orkut auf ihre privaten Daten zugreifen oder ihre Daten für andere Websites oder Gadgets freigeben können. Der OAuth-Proxy erleichtert Entwicklern von Gadgets die Entwicklung, indem viele Authentifizierungsdetails von OAuth ausgeblendet werden. Der Proxy basiert auf dem Open-Source-Projekt Shindig, einer Implementierung der Gadget-Spezifikation.

Hinweis: Der OAuth-Proxy wird nur für Gadgets unterstützt, die die gadgets.* API verwenden und in OpenSocial-Containern ausgeführt werden. Es wird für die alte 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, geschieht Folgendes:

  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 Starten eines neuen Fensters mit dieser URL bereitstellen.
  3. Auf der Genehmigungsseite entscheidet sich der Nutzer für den Zugriff auf Ihr Gadget. Wenn der Vorgang erfolgreich ist, wird der Nutzer zur angegebenen oauth_callback-Seite weitergeleitet. Die beste Nutzererfahrung erzielen Sie mit http://oauth.gmodules.com/gadgets/oauthcallback.
  4. Als Nächstes schließt der Nutzer das Pop-up-Fenster. Wenn Sie Ihr Gadget über die Zustimmung des Nutzers informieren möchten, können Sie einen Pop-up-Handler verwenden, der das Schließen des Genehmigungsfensters erkennt. Alternativ kann Ihr Gadget einen Link (z.B. Ich habe Zugriff gewährt) anzeigen, auf den der Nutzer klickt, 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 war erfolgreich.
  6. Ihr Gadget ist authentifiziert und kann normal funktionieren.

Gadget einrichten

Für den Zugriff auf eine oder mehrere Google Data APIs müssen Sie Ihrem Gadget zuerst mitteilen, dass OAuth als Authentifizierungsmethode verwendet werden soll. Füge im Abschnitt <ModulePrefs> der XML deines 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 der in diesem Parameter verwendeten scope zugreifen. In diesem Beispiel hat das Gadget Zugriff auf Blogger- und Kalenderdaten. Ein Gadget kann wie in diesem Beispiel Daten für einen einzelnen Bereich oder für mehrere Bereiche anfordern.
oauth_callback
Ein optionaler Parameter in der Autorisierungs-URL. Die OAuth-Genehmigungsseite leitet zu dieser URL weiter, nachdem der Benutzer den Zugriff auf Daten genehmigt hat. Du solltest diesen Parameter auf http://oauth.gmodules.com/gadgets/oauthcallback setzen, damit Nutzer dein Gadget optimal nutzen können. Diese Seite enthält ein JavaScript-Snippet, das das Pop-up-Fenster automatisch schließt. Alternativ können Sie diesen Parameter so einstellen, dass er auf Ihre eigene genehmigte Seite verweist. Sie können den Parameter auch einfach leer lassen.

Auf einen authentifizierten Google Data API-Feed zugreifen

Sobald der Nutzer über Ihr Gadget authentifiziert wurde, ist der Zugriff auf eine Google Data API über die JavaScript-Clientbibliothek der Google Data APIs ganz einfach. Informationen zur Verwendung der Bibliothek im OAuth-Proxy finden Sie unter JavaScript-Clientbibliothek verwenden.

Weitere Informationen zu Gadgets

Ausführliche Informationen zum Erstellen von Google Data API-Gadgets, einschließlich Details zum OAuth-Proxy, einen Artikel zum Einstieg und zur Spezifikation gadgets.* finden Sie in diesen zusätzlichen Ressourcen:

Nach oben