68 Stimmen

Authentifizierung mit OAuth2 für eine Anwendung *und* eine Website

Ich entwickle eine Website, auf die hauptsächlich über eine App zugegriffen wird, und ich möchte OAuth2 für die Benutzerregistrierung und -authentifizierung verwenden. Da es sich um eine Android-App handelt, werde ich mit dem OAuth2-Zeug von Google beginnen, da es auf Android eine anständige Benutzeroberfläche bietet.

Google erklärt, dass "Sie können das Authentifizierungssystem von Google nutzen, um die Nutzerauthentifizierung für Ihre Anwendung auszulagern. Dadurch entfällt die Notwendigkeit, einen Benutzernamen- und Passwortspeicher zu erstellen, zu pflegen und zu sichern." Das ist es, was ich tun möchte. Allerdings Wenn ich alle Beispiele und so weiter durchsehe, kann ich nur etwas über eine Website finden. または eine Anwendung einen Nutzer gegenüber den Google-Diensten authentifizieren.

Und tatsächlich, wenn ich meine App ("Client") bei Googles OAuth2 registrieren möchte, gibt es Optionen für Website-Clients und "installierte" Clients (d. h. eine mobile App), aber nicht für beide. Ich kann zwei getrennte Clients erstellen, aber ich habe den OAuth2-Entwurf gelesen und ich denke, dass es ein Problem geben wird, das ich jetzt erklären werde.

So habe ich mir das vorgestellt:

OAuth2 flow diagram

  1. Der Benutzer fordert MyApp auf, auf seine privaten Daten zuzugreifen.
  2. Die App verwendet die Android AccountManager Klasse, um ein Zugriffs-Token für die APIs von Google anzufordern.
  3. Android sagt dem Benutzer: "Die App 'MyApp' möchte auf Ihre Basisinformationen bei Google zugreifen. Ist das in Ordnung?"
  4. Der Benutzer sagt ja.
  5. AccountManager stellt mit den auf dem Telefon gespeicherten Anmeldedaten eine Verbindung zum OAuth2-Server von Google her und fordert ein Zugriffstoken an.
  6. Das Zugriffstoken (das den grünen Linien folgt) wird zurückgegeben.
  7. AccountManager gibt das Zugriffs-Token an MyApp zurück.
  8. MyApp sendet eine Anfrage an MySite für die privaten Daten des Benutzers, einschließlich des Zugangstokens.
  9. MySite muss den Benutzer anhand des Zugriffstokens verifizieren. Es validiert das Token wie hier beschrieben mit Google - "Google, ist dieses Token gültig?".
  10. Nun, was ich wollen Ich denke, dass Google sagen wird: "Ja, derjenige, der es Ihnen gegeben hat, ist tatsächlich dieser Nutzer.", aber ich denke, dass es (auf der Grundlage des OAuth2-Entwurfs und der Google-Dokumentation) tatsächlich sagen wird: "Auf keinen Fall! Dieses Token ist nur für MyApp gültig, und Sie sind MySite. GTFO!".

Wie sollte ich also vorgehen? Und BITTE sagen Sie nicht "Verwenden Sie OpenID" oder "Verwenden Sie kein OAuth2" oder andere ähnlich wenig hilfreiche Antworten. Oh, und ich würde wirklich gerne weiterhin die nette AccountManager UI statt beschissenem Popup WebView s

Editar

Die vorläufige Antwort von Nikolay (ich werde berichten, wenn es funktioniert!) lautet, dass es tatsächlich funktionieren sollte und dass es den Google-Servern egal sein wird, woher das Zugriffstoken stammt. Scheint mir ein bisschen unsicher, aber ich werde sehen, ob es funktioniert!

Update

Ich habe dieses Muster mit Facebook anstelle von Google umgesetzt, und es funktioniert hervorragend. Dem OAuth2-Server ist es egal, woher das Zugriffstoken stammt. Zumindest der von Facebook nicht, also nehme ich an, der von Google auch nicht.

In Anbetracht dessen ist es eine sehr, sehr schlechte Idee, Zugangstoken zu speichern! Aber wir wollen auch nicht auf die Server von Facebook/Google zugreifen müssen, um die Authentifizierung für cada Antrag, da er alles verlangsamen würde. Wahrscheinlich ist es am besten, ein zusätzliches Authentifizierungs-Cookie für Ihre Website hinzuzufügen, das Sie aushändigen, wenn das Zugriffs-Token validiert ist, aber eine einfachere Möglichkeit ist, das Zugriffs-Token wie ein Passwort zu behandeln und einen Hash davon zu speichern. Sie brauchen es auch nicht zu salzen, da Zugangstoken wirklich sehr lang sind. Die obigen Schritte werden also zu etwas wie:

9. MySite muss den Benutzer anhand des Zugangstokens verifizieren. Zunächst wird der Cache mit den gehashten gültigen Zugangstoken überprüft. Wenn der Hash des Tokens dort gefunden wird, weiß sie, dass der Benutzer authentifiziert ist. Andernfalls prüft es mit Google wie hier beschrieben mit Google - "Google, ist dieses Token gültig?".

10. Wenn Google sagt, dass das Zugriffstoken ungültig ist, sagen wir dem Nutzer, dass er verschwinden soll. Andernfalls sagt Google "Ja, das ist ein gültiger Nutzer" und wir überprüfen unsere Datenbank für registrierte Nutzer. Wenn der Google-Nutzername (oder die Facebook-ID, wenn Sie Facebook verwenden) nicht gefunden wird, können wir einen neuen Nutzer erstellen. Anschließend wird der Hashwert des Zugriffstokens zwischengespeichert.

5voto

Wolfram Arnold Punkte 7013

Ich habe gerade gebucht eine Antwort zu einer ähnlichen Frage bei StackOverflow.

Google nennt dies Hybride Anwendungen und erklärt, wie ein "Android-App erhält Offline-Zugang für Web-Backend" .

Das Wesentliche dabei ist, dass Sie einen massierten scope Zeichenkette in GoogleAuthUtil.getToken um einen Autorisierungscode (kein OAuth2-Token) zu erhalten. Dieser Autorisierungscode kann von Ihrer mobilen App an Ihren Server weitergegeben und gegen ein OAuth2-Token und ein Refresh-Token ausgetauscht werden, gemäß dieses Schema .

Les scope Parameter muss etwa so aussehen:

oauth2:server:client_id:<your_server_client_it>:api_scope:<scope_url_1> <scope_url_2> ...

2voto

Burcu Dogan Punkte 9017

Sie können das von der mobilen Anwendung abgerufene Zugangstoken an anderer Stelle verwenden. Drive SDK hat eine schöne und einfache Einführung, die durch den Fluss auf https://developers.google.com/drive/quickstart-Android

2voto

Es beschreibt genau das, was Sie wollen: https://developers.google.com/identity/protocols/CrossClientAuth

1voto

Nikolay Elenkov Punkte 52201

Wahrscheinlich benötigen Sie OpenID Connect, das OAuth-Tokens für die Authentifizierung verwendet. Wie für AccountManager ist die derzeitige OAuth-Unterstützung ein wenig hakelig, die neue Google Play-Dienste die "bald" veröffentlicht werden soll, sollte dies hoffentlich besser werden. Siehe hier für eine Demo .

1voto

user1978019 Punkte 2556

Zumindest bei Google läuft das Zugriffstoken irgendwann ab. Aus diesem Grund ist das Android [AccountManager](http://developer.android.com/reference/android/accounts/AccountManager.html) hat die invalidateAuthToken Methode - das zwischengespeicherte Zugriffstoken ist abgelaufen, und Sie müssen der AccountManager Ihnen nicht mehr den alten, sondern einen neuen zu geben. Dies macht es etwas sicherer, das Token zwischenzuspeichern, da das Token selbst Ihnen keinen ewigen Zugang als dieser Benutzer gibt. Stattdessen besagt es, wenn es gültig ist, lediglich, dass dieses Token irgendwann in der jüngsten Vergangenheit von einer vertrauenswürdigen Quelle erworben wurde.

Hier sind ein paar Dinge, die ich bei der Arbeit mit Token als hilfreich empfunden habe. Das erste ist Googles Tokeninfo-Endpunkt. Das Token selbst ist nur Base64-kodiertes JSON. Das bedeutet, dass es nicht verschlüsselt ist, so dass Sie sicher sein müssen, HTTPS für die Kommunikation zu verwenden. Es bedeutet aber auch, dass Sie das Token untersuchen können und eine bessere Vorstellung davon haben, was vor sich geht.

https://www.googleapis.com/oauth2/v1/tokeninfo?id_token=

Wenn Ihr Token "abcdef" wäre, würden Sie zu navigieren:

https://www.googleapis.com/oauth2/v1/tokeninfo?id_token=abcdef

und Google würde das Token für Sie auspacken. Es handelt sich um ein einfaches JSON-Objekt, das ein Feld "expires_in" enthält, das die Anzahl der Sekunden angibt, für die das Token noch gültig ist. Bei 6:03 im Video unten sehen Sie das entpackte Token:

https://developers.google.com/events/io/sessions/383266187

Dieses Video enthält einen umfassenden Überblick über OAuth2 und ist es wert, in seiner Gesamtheit angesehen zu werden, wenn Sie mit OAuth und Token zu tun haben werden. Der Sprecher geht auch auf andere Formen von Oauth2-Tokens ein, die keine Zugriffstoken sind und nicht ablaufen.

Eine weitere nützliche Ressource ist der OAuth Playground. Damit können Sie grundlegende Dinge tun, wie z. B. Bereiche anfordern, Anfragen erstellen und Token zurückerhalten. Dieser Link scheint nur sporadisch zu funktionieren, und auf Chrome musste ich die OAuth Playground-App installieren:

https://developers.google.com/oauthplayground/

Und hier ist ein Tutorial von Tim Bray, dem Sprecher im Video, das erklärt, wie man Zugangstoken verwendet, um von einer Android-App aus mit einem Server zu kommunizieren. Dies war für mich nützlich, weil ich zu verstehen begann, wie die verschiedenen Dinge in der Google API Console zusammenarbeiten:

http://Android-developers.blogspot.in/2013/01/verifying-back-end-calls-from-Android.html

Was die eigentliche Antwort auf Ihre Frage betrifft, würde ich sagen, dass Sie das Zugriffstoken niemals auf dem Server zwischenspeichern müssen. Wie im obigen Link Verifizierung von Backend-Aufrufen von Android erklärt, ist die Verifizierung eines Tokens fast immer ein schneller statischer Aufruf, was bedeutet, dass es keinen Grund gibt, die Token zu cachen:

Die Bibliotheken können die Google-Zertifikate zwischenspeichern und aktualisieren sie nur bei Bedarf, so dass die Überprüfung (fast immer) ein schneller statischer Aufruf ist.

Schließlich können Sie auch die AccountManager um Zugangstokens zu erhalten. Google ermutigt jetzt jedoch stattdessen die Verwendung der [GoogleAuthUtil](http://developer.android.com/reference/com/google/android/gms/auth/GoogleAuthUtil.html) Klasse in der Play Services-Bibliothek zu verwenden:

Kurz gesagt, was ist der Unterschied zwischen den OAuth2-Anfragen getAuthToken und getToken

Beachten Sie den Kommentar von Tim Bray, demselben Mann wie in den obigen Links, der sagt, dass sie ihre Bemühungen in die GoogleAuthUtil Route. Beachten Sie jedoch, dass dies bedeutet, dass Sie auf die Google-Authentifizierung beschränkt wären. Ich glaube, dass die AccountManager verwendet werden, um z. B. ein Facebook-Token zu erhalten, was nicht der Fall ist bei GoogleAuthUtil .

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X