Ich bin sicher, dass Sie ein oder mehrere Social-Media-Konten haben.
Sei es Facebook, Twitter, YouTube, Google, GitHub
oder viele andere solche Dienstleister, bei denen Sie Telefon und Konto registriert haben.
Nun
sind diese Dienstanbieter wiederum bereit, Authentifizierungsdienste in Ihrem Namen bereitzustellen.
So sehen Sie beispielsweise die Verbreitung einer Reihe von Websites
und mobilen Anwendungen, bei denen Sie sich
mit Ihren Social-Media-Konten anmelden dürfen.
Nun, wie funktioniert das eigentlich?
Viele dieser Social-Media-Kontoanbieter fungieren
als Authentifizierungsdienstanbieter, die ein Protokoll namens OAuth verwenden.
Wir werden uns OAuth ansehen, und wie es diesen Drittanbietern ermöglicht
, Authentifizierung
in Ihrem Namen bereitzustellen und Ihnen die Anmeldung bei anderen Diensten über ihre Social-Media-Konten zu ermöglichen.
Ich bin sicher, dass Sie in der Vergangenheit über OAuth 1 und OAuth 2 gehört haben
und vielleicht von Leuten gehört haben,
die sagen, dass Facebook OAuth 2-basierte Authentifizierung
bereitstellt oder Google OAuth 2-basierte Authentifizierung bereitstellt und so weiter.
Ich bin sicher, dass Sie sich fragen müssen,
was genau sind diese OAuth1 und OAuth 2 sollen?
Jetzt sind OAuth1 und OAuth 2 Autorisierungs-Frameworks
, die auf offenen Standards basieren.
Und diese können über das Internet verwendet werden, um
Ihre Identität bei vielen Websites oder mobilen Anwendungen zu authentifizieren.
Wenn Sie diese Dienste nutzen,
sind Sie abhängig von einem der Social-Media-Accounts wie Facebook
, Google, Twitter, Microsoft, Instagram
, GitHub, DigitalOcean und vielen mehr,
die diese Authentifizierungsdienste für andere bereitstellen.
Diese Authentifizierungsdienstanbieter versprechen
den Benutzern dieses Authentifizierungsdienstes, dass sie die Identität
des Benutzers anhand
ihrer Anmeldeinformationen für diese Social-Media-Dienste authentifizieren.
Jetzt gibt es einen ergänzenden Service OpenID.
Aber natürlich, nicht mit OAuth verwandt, sondern bietet eine ähnliche Art von Service.
Aber die meisten standardmäßigen Social-Media-Dienstleister,
wie Sie hier sehen werden,
bieten heute OAuth 2-basierte Dienste an.
Wie ich bereits erwähnt habe, sind OAuth1 und OAuth 2 Authentifizierungsprotokolle,
und OAuth 1 war das erste Protokoll, das entstanden ist.
Dies wurde von Twitter entwickelt,
Blaine Cook ist die Person dahinter,
und dies ist in der Internet Engineering Task Force, RFC 5849 dokumentiert.
Also, wenn Sie die blutigen Details darüber lesen wollen, wie diese Protokolle funktionieren,
ist das der Ort, um das zu finden. Das
OAuth 2-Protokoll wurde von OAuth 1 entwickelt, um es einfacher
zu machen und eine einfachere Möglichkeit für die Client-Entwicklung zu bieten.
Und dies ist in IETF RFC 6749 dokumentiert und danach
kam eine weitere Inhaber-Token Verwendung in IETF RFC 6750 zustande.
Aus unserer Sicht
wollen wir nicht wirklich in Details darüber eingehen, wie diese Protokolle tatsächlich funktionieren.
Stattdessen ist alles, was wir daran interessiert sind,
wie nutzen wir diese für die Benutzerauthentifizierung innerhalb unserer Webanwendung
oder innerhalb unserer mobilen Anwendung,
wenn wir den Benutzer beim
Express-Server authentifizieren müssen, auf dem wir bisher aufbauen?
Jetzt konzentrieren wir uns in erster Linie auf OAuth 2,
weil
wir in der Übung die Verwendung von Facebook als OAuth 2-Authentifizierungsdienstanbieter betrachten werden,
und hier müssen wir
ein paar Begriffe verstehen, um zu sehen, wie genau dieses OAuth 2-Protokoll funktioniert.
Zumindest die bare-bone Details, wie das Protokoll selbst funktioniert.
Jetzt sprechen
wir im Falle von OAuth 2 immer über einen Ressourcenbesitz.
In diesem Fall
ist die Ressource, auf die ich verweise, nicht
die Ressource, die auf dem Express-Server gespeichert ist.
Stattdessen
ist die Ressource, auf die wir hier verweisen, die Identität des Benutzers.
Nun
möchte jeder Server, wie der Express-Server, den wir erstellt haben, Zugriff auf diese Ressource erhalten,
das ist Ihre Identität.
Nun, wo ist Ihre Identität?
Ihre Identität wird auf einem
dieser Social-Media-Authentifizierungsdienstleister wie Facebook und so weiter gespeichert,
da Sie bereits ein Konto auf diesen Social-Media-Websites erstellt haben.
So werden
beispielsweise Ihre Informationen oder Ihre Identitätsinformationen oder Ihre Profilinformationen bei Facebook gespeichert.
Nun möchte Ihr Express-Server Zugriff auf Ihre Identität erhalten und
überprüfen, ob Sie wirklich versuchen, auf den Express-Server zuzugreifen.
In diesem Fall
fungiert der Express-Server, den wir entwickelt haben, als Client-Anwendung.
Also, hier ist die Client-Anwendung,
die die Website oder die mobile App, die
Zugriff auf den Ressourcenserver will, um die Informationen über Sie zu erhalten.
Was ist ein Ressourcenserver, von dem wir sprechen?
Dies ist der Facebook OAuth Authentifizierungsserver,
der auch Ihre Profilinformationen auf Anfrage zur Verfügung stellt.
Natürlich werden Sie Ihre Profilinformationen nicht nach dem Zufallsprinzip weiterleiten.
Stattdessen möchten Sie überprüfen können, ob Sie einem authentifizierten
Dienstanbieter oder einem authentifizierten Server Zugriff auf Ihre Profilinformationen gewähren.
Nun, hier wird sich Ihre Client-Anwendung oder der Express-Server hier
zum Beispiel auf Facebook mit einem Konto registrieren, das besagt, dass ich eine App betreibe,
und ich möchte mich als potenzielle Quelle registrieren, die
Sie nähern kann, um Benutzer zu authentifizieren, wenn sie
Zugriff auf deren Profil, das auf Ihrer Website gespeichert ist.
Der Express-Server,
in diesem Fall als Client-Anwendung fungiert,
registriert sich auf Facebook und erhält eine ClientID und ein Kundengeheimnis von Facebook.
Wenn sich der Express-Server auf Facebook registriert,
benötigen Sie ein Konto auf Facebook,
ein authentifiziertes Konto auf Facebook, mit
dem Sie diese App auf Facebook einrichten.
Sobald Sie sich registriert haben,
erhalten Sie Zugriff auf eine ClientID und ein Kundengeheimnis.
Nun
ist der Ressourcenserver, wie ich bereits erwähnt habe, der Server, der die geschützten Daten hostet.
Geschützte Daten, d. h. das Profil des Benutzers, der auf den Express-Server zugreifen möchte.
Der Express-Server möchte also auf diesen Ressourcenserver zugreifen
und die Profildaten des Benutzers erhalten, der auf den Express-Server zugreifen möchte.
Also, Sie sehen die Beziehung hier.
Wenn ich also über eine Clientanwendung spreche,
meine ich nicht ihre Front-End-Anwendung,
sondern ihren Express-Server, der versucht, Ihnen
Zugriff auf Ressourcen zu gewähren, die es auf seiner Website hat.
Aber der Express-Server,
um Ihnen den Zugriff zu ermöglichen,
benötigt Zugriff auf Ihren Facebook-Ressourcenserver, der
Sie authentifiziert und Ihre Profilinformationen an den Express-Server zur Verfügung stellt.
Also, der Ressourcenserver, von dem ich hier spreche,
ist der OAuth 2-Authentifizierungsserver von Facebook
plus der Ressourcenserver, der Ihnen Zugriff auf die Profilinformationen des Benutzers gibt.
Und der Autorisierungsserver ist der Server, der
jemanden autorisiert, auf
den Ressourcenserver zuzugreifen, um die Profilinformationen abzurufen.
Nun ist der Benutzer derjenige, der die Profilinformationen auf dem Ressourcenserver hat.
Der Benutzer sollte den Express-Server autorisieren, zu
diesem Ressourcenserver zu gehen, um die Profilinformationen abzurufen.
Wenn der Benutzer jedoch den Express-Server autorisieren muss,
muss sich der Benutzer beim Facebook-Konto anmelden
und dann Informationen von Facebook erhalten, die als Zugriffstoken aufgerufen
werden, die der Benutzer dann an Express-Server weitergibt.
Nun, wenn das Zugriffstoken von Facebook über das OAuth 2-Protokoll erhalten wird,
wird das Zugriffstoken in Bezug auf das
Zulassen dieser Client-Anwendung oder des Express-Servers ausgegeben
, der bereits auf Facebook registriert ist und sagt, dass
dieser Client-Server ich autorisieren werde,
auf ihre Profilinformationen von ihrem Facebook-OAuth-Dienstanbieter.
Also, wieder, das ist ein bisschen verwirrend.
Wir sehen ein Diagramm, in dem
Ihnen dieser Informationsfluss ein wenig deutlicher erklärt wird.
Ein Punkt, den ich gerade erwähnt habe, ist ein OAuth-Token oder das Zugriffstoken.
Was ist dieses Zugriffstoken?
Das Zugriffstoken ist etwas, das der Autorisierungsserver für Sie ausgibt.
Welcher Autorisierungsserver?
Dies ist der OAuth 2-Autorisierungsserver des Drittanbieters, der
Facebook-Server, in diesem Beispiel.
Sie sind also Express-Server-Anwendung.
Jetzt möchten Sie als Front-End-Benutzer
auf etwas von der Express-Serveranwendung zugreifen.
Die Express-Server-Anwendung wird Ihnen mitteilen, dass Sie
sich von Facebook authentifizieren und dann Zugriffstoken von Facebook erhalten.
Dieses Zugriffstoken wird an
den Front-End-Benutzer von Facebook ausgegeben, wenn sich der Benutzer in seinem Facebook-Konto anmeldet.
Jetzt wird dieses Zugriffstoken im Namen der Client-Anwendung,
Express-Server, ausgegeben, die sich bereits bei Facebook registriert hat.
Damit der Benutzer auf Facebook zugreifen kann, um sein Zugriffstoken zu erhalten,
benötigt der Benutzer die Client-ID der Client-Anwendung oder der Express-Anwendung.
Diese Client-ID ist also in
die Front-End-Anwendung eingebettet, die dieser Express-Server für Sie bereitstellt. Der
Express-Server stellt also eine Website bereit, auf die Sie zugreifen,
dann enthält diese Website Code,
in dem die Client-ID dieses Express-Servers bereits eingebettet ist.
Eine weitere Information, die ich erwähnte, ist ein Kundengeheimnis.
Nun, in dem Authentifizierungsfluss, über den ich sprechen werde,
wird das Clientgeheimnis niemandem offenbart.
Das Clientgeheimnis wird nur auf der Express-Serverseite angezeigt.
Wenn der Express-Server versucht, sich zu authentifizieren und
Zugriff auf das Profil des Benutzers von Facebook zu erhalten,
die Client-Anwendung,
sendet der Express-Server sowohl die Client-ID als auch das Client-Geheimnis,
zusammen mit dem Zugriffstoken, das der Benutzer an Facebook zur Verfügung stellt.
Und Facebook wiederum
autorisiert ihre Client-Anwendung, auf
den Ressourcenserver zuzugreifen, um die Profildaten des Benutzers zu erhalten.
Und sobald die Profildaten des Nutzers vom Facebook-Ressourcenserver abgerufen werden,
wird mein Express-Server ein Konto
für diesen bestimmten Benutzer erstellen, der sie mit seinem Facebook-Konto angemeldet hat.
Geben Sie anschließend dem Benutzer ein JSON-Web-Token an,
das der Benutzer dann verwenden kann, um auf
die Ressourcen zuzugreifen, die auf dem Express-Server gespeichert sind.
Also, noch einmal, um das zusammenzufassen,
habe ich hier ein Diagramm, um Ihnen das etwas genauer zu erklären.
Darüber hinaus
gibt es auch ein Aktualisierungstoken.
Wenn ein Zugriffstoken vom Facebook OAuth 2-Server ausgegeben wird,
hat das Zugriffstoken eine begrenzte Lebensdauer.
Danach wird das Zugriffstoken ungültig.
Das Zugriffstoken muss also vertraulich behandelt werden.
All dieser Austausch von Token zwischen den verschiedenen Sites
wird also in einer verschlüsselten Angelegenheit unter Verwendung des HTTPS-Protokolls durchgeführt.
Stellen Sie also sicher, dass Sie beim Senden Ihres Zugriffstoken von
Ihrer Benutzerfront-End-Anwendung an den Express-Server
nur das Zugriffstoken über HTTPS und nicht über HTTP senden.
Dies ist sehr wichtig, weil Sie nicht
möchten, dass Ihr Zugriffstoken jemandem offenbart wird
, weil jeder, der eines Ihrer Zugriffstoken erhalten kann, vorgeben kann,
seine Clientanwendung zu sein und dann Zugriff auf Ihr Benutzerprofil zu erhalten.
Das ist also sehr wichtig.
Da das Zugriffstoken jetzt eine begrenzte Lebensdauer hat,
gibt es auch ein entsprechendes Aktualisierungstoken,
das verwendet werden kann, um ein abgelaufenes Zugriffstoken zu aktualisieren.
Nun, in der Art von Fluss, den wir
mit unserer Anwendung in der Übung verwenden
werden, können wir das Aktualisierungstoken nicht verwenden.
Jedes Mal, wenn der Benutzer
den Express-Server autorisieren möchte, um die Profilinformationen von Facebook abzurufen,
muss der Benutzer explizit
ein neues Zugriffstoken bereitstellen, das von Facebook erhalten wird.
Der eine Teil, den ich gerade kurz erwähnt habe,
aber ich habe nicht ausgearbeitet,
ist, wie funktioniert die Client-Anwendung, der Express-Server,
die Waage, wie registriert sie sich beim OAuth 2-Dienstanbieter?
Jetzt bieten viele der OAuth 2-Dienstanbieter
eine Möglichkeit, eine App auf ihrer Website zu registrieren.
So
registriert sich eine Client-Anwendung, die Express-Server in unserem Beispiel, als Client-Anwendung auf dem OAuth-Dienstanbieter.
Wie Sie in der Übung sehen werden, ist der
allererste Schritt, den wir tun werden, um sich mit
unserem Konto bei Facebook anzumelden und dann eine App auf Facebook-Seite zu erstellen.
Wenn Sie das tun, wird Facebook Ihnen eine Client-App-ID und ein Clientgeheimnis ausgeben.
Dieses Verfahren gilt für viele andere OAuth-Dienstanbieter, da
dies der allgemeine Ablauf ist, über den das OAuth 2-Protokoll spricht.
Daher sind die Client-App-ID und das Client-Geheimnis nützlich für uns, um
unsere Identität gegenüber
dem OAuth Server beweisen zu können, wenn wir ein Zugriffstoken übergeben, das wir vom Benutzer erhalten.
Jetzt gibt es auch eine Umleitungs-URL, die Sie
registrieren müssen, wenn Sie die Client-Anwendung registrieren,
und Sie werden sehen, wie ich das in den Schritten ausführen, die ich die
App auf der Facebook-Website registriere.
Nun, um den Informationsfluss zusammenzufassen
, über den wir im früheren Fall kurz gesprochen haben,
lassen Sie mich an dieser Stelle beginnen.
Der erste Punkt, den Sie betrachten müssen, ist der Ressourcenbesitzer.
Der Ressourcenbesitzer hier ist also der Benutzer, der
sein Social-Media-Konto verwenden wird.
Facebook
hat in diesem Beispiel die Authentifizierung für den Benutzer.
Der Ressourcenbesitzer ist also derjenige, der das Profil über die Ressource hat.
Und diese Profilinformationen für jeden Facebook-Account
wurden sie auf dem Facebook-Server gespeichert.
Und so stellt der Facebook-Server hier den Ressourcenserver zur Verfügung.
Das ist also der OAuth Service Provider, den Sie auf
der rechten Seite dieses Bildes hier sehen.
Stellen Sie sich also vor, der Facebook-Server auf der rechten Seite, diese Client-Anwendung,
die den Rest API-Server hat,
den Express-Server, den wir implementiert haben,
ist in diesem Fall eine Client-Anwendung,
und der Ressourcenbesitzer ist der Benutzer.
URL-Front-End-Benutzer, die
Sie autorisieren, zu Facebook zu gehen, um die Anmeldeinformationen des Benutzers zu überprüfen.
Wenn Sie also auf Informationen auf der Clientseite zugreifen möchten,
müssen Sie zuerst
diese Client-Anwendung autorisieren, um
Zugriff auf Ihre Profilinformationen zu erhalten.
Also die Client-Anwendung,
wenn sie als Web-App fungiert,
wird es eine entsprechende Schaltfläche darin bereitstellen, die sich mit Facebook einloggen sagt.
Und wenn Sie also auf die Schaltfläche klicken, wird
im Wesentlichen der erste Schritt initiiert.
Die Benutzerautorisierungsanforderung wird initiiert.
Ihre Client-Anwendung,
über den Benutzeragent,
ist der Benutzeragent im Grunde die Client-Anwendung, die Front-End-Anwendung.
Es könnte die Angular-App sein, die wir entwickelt haben oder diese mobile App,
ob es Ionic ist oder ob es
eine NativeScript-App ist, die wir in den Kursen früher in
der Spezialisierung entwickelt haben, oder sogar eine native App wie eine iOS-App oder eine Android-App.
All diese fungieren als User-Agent.
Also der User-Agent,
sie verwenden einen Autorisierungsanforderungsprozess durch
den User-Agent an den Autorisierungsserver
, der der Facebook-Server ist.
Wenn das nun übergeben wird,
muss der Ressourcenbesitzer oder der Benutzer, der versucht, Zugriff auf sein Profil dieser Client-Anwendung zu gewähren, Facebook autorisieren, um
diese Informationen mit der Client-Anwendung teilen zu können.
In dem impliziten Flow Grant-Ansatz, den wir in
unserem Beispiel hier und auch in der folgenden Übung verwenden,
ist der implizite Flow Grant-Ansatz
der am besten geeignete Ansatz, wenn Sie eine Web-App mit
einem Framework wie Angular oder der hybriden mobilen App
mit Ionic oder einem NativeScript oder sogar eine native App.
Der implizite Flow Grant-Ansatz ist viel einfachere Art,
die OAuth 2 für solche Anwendungen zu betreiben.
Dann klickt der Ressourcenbesitzer auf die Anmeldeschaltfläche,
dann fordert der Autorisierungsserver den Ressourcenbesitzer mit den Informationen auf, die besagen:
„Diese Client-Anwendung möchte auf Ihre Profilinformationen zugreifen.
Genehmigen Sie es?“
Und so wird dies von Facebook aufgetaucht werden,
und dann werden Sie auf eine Schaltfläche klicken, die sagt: „Ja,
ich autorisieren diese Client-Anwendung, um in meinem Namen zuzugreifen.“
An diesem Punkt
generiert der Autorisierungsserver auf Facebook, der OAuth 2-Autorisierungsserver auf Facebook, ein Zugriffstoken.
Um dieses Zugriffstoken zu generieren,
verwendet es die Client-ID für diese Client-Anwendung,
die Express-Server-Anwendung, die wir registrieren.
Daher sollte die Client-ID Teil des Benutzeragenten sein, den dieser Benutzer verwendet.
Diese Client-ID wird also in die Angular-App,
die Ionic oder die NativeScript-App oder sogar eine iOS- oder Android-App eingebettet.
Die Client-ID wird dann vom
User-Agent verwendet, um den Autorisierungsserver zu drehen und zu sagen:
„Diese Client-App-Anwendung will Zugriff auf mein Profil,
und ich bin bereit, Sie zu autorisieren, den Zugriff auf das Profil zu erlauben.“
Zu diesem Zeitpunkt
sendet der Autorisierungsserver in diesem Fall ein Zugriffstoken an den User-Agent.
Denken Sie also daran, dass dieses Zugriffstoken in den Benutzeragenten kommt,
d. h. die mobile App oder ihre Angular-App, die von uns implementiert wird.
Dann wird dieser Benutzeragent dieses Zugriffstoken nehmen und
dann dieses Zugriffstoken an diese Clientanwendung übergeben.
Also die OAuth, um sich
anzumelden, aber das Zugriffstoken wird an die Clientanwendung übergeben,
der Express-Server in diesem Fall
an einer bestimmten Route auf dem Router des Benutzers,
die Authentifizierungsroute auf dem Clientanwendungsstandort.
Nun, zuvor, sahen wir die Verwendung der lokalen Authentifizierung,
wo wir eine Anfrage gesendet Schrägstrich Benutzerschrägstrich anmelden.
Nun, damit dies in unserer App funktioniert,
werden wir eine andere für Schrägstrich Benutzer einrichten,
Schrägstrich Facebook, Schrägstrich und so weiter.
Also eine andere URL, auf der wir dieses Zugriffstoken an den Express-Server zur Verfügung stellen.
Wenn dieses Zugriffstoken nun vom Express-Server abgerufen
wird, nimmt der Express-Server dieses Zugriffstoken
und
sendet dann zusammen mit seiner Client-ID und dem Clientgeheimnis diese Informationen an den Autorisierungsserver.
Und der Autorisierungsserver erlaubt dann seiner Clientanwendung
den Zugriff auf den Ressourcenserver, um die Profilinformationen zu erhalten.
Und so werden die Profilinformationen in Schritt 6 zurückgesendet,
in diesem Fall zurück an die Client-Anwendung.
Wenn die Clientanwendung die Profilinformationen für den Benutzer
abruft, erstellt die Clientanwendung ein neues Konto für
den Benutzer auf jeder Site, wenn kein Konto vorhanden ist.
Wenn sich dieser Benutzer bereits früher mit seiner Facebook-ID angemeldet hat, ist
bereits ein Konto vorhanden, so dass die Client-Anwendung und der Rest API-Server
einfach kreuzen, um zu sehen, dass dieses Benutzerkonto bereits existiert.
Und zu diesem Zeitpunkt
wird der Benutzer bei der Drittanbieter-Anmeldefunktion authentifiziert,
die vom OAuth 2-Authentifizierungsdienst von Facebook bereitgestellt wird.
An diesem Punkt generiert die Clientanwendung ein JSON-Web-Token,
in dem Beispiel, das wir implementieren und trainieren,
und übergeben dann dieses JSON-Web-Token zurück an den Benutzeragenten oder die Front-End-Anwendung
oder die Angular-App oder die Ionic App
oder die NativeScript-App.
Dann wird das JSON-Web-Token anschließend vom Benutzer verwendet, um
sich zu authentifizieren, wenn er auf
Ressourcen zugreifen möchte, die auf dem Express-Server gespeichert sind.
Sobald Sie also das JSON Web Token,
alle nachfolgenden Operationen, erhalten haben, haben Sie bereits gesehen, wie Sie das mit JSON Web Token tun können.
Sobald Sie also das JSON Web Token erhalten,
ist Ihre Aufgabe erledigt,
und Sie können dann mit dem normalen Vorgang von diesem Punkt an fortfahren.
Wenn das JSON-Web-Token abläuft,
müssen Sie den gesamten Prozess der erneuten Authentifizierung durchlaufen und
anschließend den Benutzern den Zugriff auf Informationen auf Ihrer Website ermöglichen.
Also, mit diesem schnellen Verständnis, wie OAuth 2-Operationen funktionieren
, wieder, wie Sie sehen, gibt es hier viele Details.
Aber zum Glück müssen wir uns nicht mit all diesen Details beschäftigen, weil wir
ein Knotenmodul verwenden, das sich um viele dieser Details in unserem Namen kümmert.
Da wir unseren Express-Server bereits für die Verwendung von Passport eingerichtet haben,
können wir nun einen weiteren Knotenmodul-Code als Passport-Facebook-Token-Modul verwenden.
Das Passport-Facebook-Token-Modul implementiert im Wesentlichen
den impliziten Grant-Ansatz, über den ich früher gesprochen habe.
Und dann können Sie
eine neue Strategie in Ihrer Passport-Strategie innerhalb Ihrer Anwendung initialisieren.
Damit das Passport-Facebook-Token-Modul Ihnen ermöglicht,
eine neue Passport-Authentifizierungsstrategie für die Verwendung von Facebook-basierter OAuth 2-API einzurichten.
Und so, um dieses Modul zu nutzen,
installieren Sie dies, indem Sie sagen, Vergangenheit npm installieren Pass - Facebook-Token,
minus sparen, und dann, wenn Sie das installiert,
dann werden Sie eine Facebook-Strategie innerhalb Ihrer Anwendung konfigurieren, und danach
nutzen Sie dies, um die Strategie zu konfigurieren , um Ihren Passport
zu nutzen, wenn wir die OAuth 2-basierte Authentifizierung für unsere Anwendung nutzen.
Mit diesem schnellen Verständnis von OAuth 2
gehen wir zur Übung über,
wo wir unseren Express-Server so konfigurieren werden, dass er tatsächlich
diesen impliziten Grant-Ansatz nutzt, um uns zu ermöglichen
, unsere Identität gegenüber dem Express-Server zu überprüfen und
danach Zugang zu den Ressourcen, den Gerichten,
die Werbeaktionen und die Informationen der Führer, die auf unserem Express-Server gespeichert sind.