Client-Geheimnis in OAuth 2.0

Um die Google Drive API zu verwenden, muss ich mit der Authentifizierung mit OAuth2.0 spielen. Und ich habe ein paar Fragen dazu.

1. Client-ID und Client-Geheimnis werden verwendet, um zu identifizieren, was meine App ist. Sie müssen jedoch fest codiert sein, wenn es sich um eine Clientanwendung handelt. So kann jeder meine App dekompilieren und aus dem Quellcode extrahieren. Bedeutet dies, dass eine schlechte App unter Verwendung der Client-ID und des Geheimnisses der guten App vorgeben kann, eine gute App zu sein? Der Benutzer würde also einen Bildschirm anzeigen, auf dem er um Erlaubnis für eine gute App bittet, obwohl er tatsächlich von einer schlechten App gefragt wird. Wenn ja, was soll ich tun? Oder sollte ich mir darüber eigentlich keine Sorgen machen?

2. In mobilen Anwendungen können wir eine Webansicht in unsere App einbetten. Und es ist einfach, das Passwortfeld in der Webansicht zu extrahieren, da die App, die um Erlaubnis bittet, tatsächlich ein "Browser" ist. OAuth in mobilen Anwendungen hat also nicht den Vorteil, dass die Clientanwendung keinen Zugriff auf die Benutzeranmeldeinformationen des Dienstanbieters hat.

Ich habe angefangen, einen Kommentar zu Ihrer Frage zu schreiben, aber dann herausgefunden, dass es zu viel zu sagen gibt. Hier sind meine Ansichten zu diesem Thema in der Antwort.

1. Ja, es gibt eine echte Möglichkeit dafür und es gab einige Exploits, die darauf basierten. Es wird empfohlen, die App in Ihrer App nicht geheim zu halten. Es gibt sogar einen Teil der Spezifikation, dass verteilte Apps dieses Token nicht verwenden sollten. Jetzt könnten Sie fragen, aber XYZ benötigt es, um zu arbeiten. In diesem Fall wird die Spezifikation nicht ordnungsgemäß implementiert, und Sie sollten A diesen Dienst nicht verwenden (nicht wahrscheinlich) oder B versuchen, das Token mithilfe einiger verschleierter Methoden zu sichern, um das Auffinden oder Verwenden Ihres Servers als Proxy zu erschweren.

   Zum Beispiel gab es einige Fehler in der Facebook-Bibliothek für Android, bei denen Token in Protokolle verloren gingen. Weitere Informationen finden Sie hier http://attack-secure.com/all-your-facebook-access-tokens-are-belong -zu uns und hier https://www.youtube.com/watch?v=twyL7Uxe6sk . Alles in allem sollten Sie besonders vorsichtig sein, wenn Sie Bibliotheken von Drittanbietern verwenden (gesunder Menschenverstand, aber wenn Token-Hijacking Ihr großes Anliegen ist, fügen Sie ein weiteres Extra zur Vorsicht hinzu).

2. Ich habe mich schon seit einiger Zeit über Punkt 2 geärgert. Ich habe sogar einige Problemumgehungen in meinen Apps durchgeführt, um die Einwilligungsseiten zu ändern (z. B. Ändern von Zoom und Design, um sie an die App anzupassen), aber nichts hinderte mich daran, Werte aus Feldern in der Webansicht mit Benutzername und Kennwort zu lesen. Daher stimme ich Ihrem zweiten Punkt voll und ganz zu und finde, dass es ein großer "Fehler" in der OAuth-Spezifikation ist. Der Punkt "App erhält keinen Zugriff auf Benutzeranmeldeinformationen" in der Spezifikation ist nur ein Traum und gibt Benutzern ein falsches Sicherheitsgefühl. Ich denke auch, dass Menschen normalerweise Verdacht haben, wenn die App sie nach ihren Facebook-, Twitter-, Dropbox- oder anderen Anmeldeinformationen fragt. Ich bezweifle, dass viele normale Leute die OAuth-Spezifikation lesen und "Jetzt bin ich sicher" sagen, aber stattdessen den gesunden Menschenverstand verwenden und im Allgemeinen keine Apps verwenden, denen sie nicht vertrauen.

Ich hatte die gleiche Frage wie die Frage 1 hier und habe kürzlich selbst recherchiert. Mein Fazit ist, dass es in Ordnung ist, "Kundengeheimnis" nicht geheim zu halten. Der Clienttyp, der die Vertraulichkeit des Clients nicht geheim hält, wird in der OAuth2-Spezifikation als "öffentlicher Client" bezeichnet. Die Möglichkeit, dass jemand, der böswillig ist, Autorisierungscode erhalten und dann auf Token zugreifen kann, wird durch die folgenden Fakten verhindert.

1. Der Kunde muss den Autorisierungscode direkt vom Benutzer und nicht vom Dienst erhalten

Selbst wenn der Benutzer den Dienst angibt, dem er dem Client vertraut, kann der Client keinen Autorisierungscode vom Dienst erhalten, indem er nur die Client-ID und das Client-Geheimnis anzeigt. Stattdessen muss der Client den Autorisierungscode direkt vom Benutzer erhalten. (Dies erfolgt normalerweise durch URL-Umleitung, auf die ich später noch eingehen werde.) Für den böswilligen Client reicht es also nicht aus, die vom Benutzer vertrauenswürdige Client-ID / das Client-Geheimnis zu kennen. Es muss den Benutzer irgendwie einbeziehen oder fälschen, um ihm den Autorisierungscode zu geben, was schwieriger sein sollte, als nur die Client-ID / das Geheimnis zu kennen.

2. Die Weiterleitungs-URL ist mit der Client-ID / dem Client-Geheimnis registriert

Nehmen wir an, der böswillige Client hat es irgendwie geschafft, den Benutzer einzubeziehen, und ihn dazu gebracht, auf der Serviceseite auf die Schaltfläche "Diese App autorisieren" zu klicken. Dadurch wird die URL-Umleitungsantwort vom Dienst an den Browser des Benutzers mit dem Autorisierungscode ausgelöst. Anschließend wird der Autorisierungscode vom Browser des Benutzers an die Umleitungs-URL gesendet, und der Client soll die Umleitungs-URL abhören, um den Autorisierungscode zu erhalten. (Die Weiterleitungs-URL kann auch localhost sein, und ich habe festgestellt, dass dies ein typischer Weg ist, auf dem ein „öffentlicher Client“ Autorisierungscode erhält.) Da diese Weiterleitungs-URL beim Dienst mit der Client-ID / dem Client-Geheimnis registriert ist, ist dies beim böswilligen Client nicht der Fall Sie können steuern, wo der Autorisierungscode angegeben wird.

Beantwortung der zweiten Frage: Google APIs schreiben aus Sicherheitsgründen vor, dass die Authentifizierung / Anmeldung nicht in der App selbst erfolgen kann (wie Webviews nicht zulässig sind) und für eine bessere Sicherheit außerhalb der App mit dem Browser durchgeführt werden muss. Dies wird weiter unten erläutert: https: //developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html