Node.js: Auth Token in API prüfen - Fragen

[Aua (Gast)]

Wieder etwas weiter: Mit diesem Beispiel und einem Azure-Testkonto 
konnte ich ein Token mit einem Microsoft-Account generieren und abholen. 
Es ist einfach ein langer encodierter String.

Dieses Beispiel habe ich verwendet:
https://docs.microsoft.com/de-de/azure/active-directory/develop/tutorial-v2-nodejs-webapp-msal

Das war sozusagen "Mittel zum Zweck" - Ich möchte ja eigentlich eine API 
damit absichern. Die API selbst funktioniert bis jetzt ohne 
Authentifizierung - also man ruft eine URL auf und bekommt einen 
JSON-Response.

Ich möchte auch weiterhin arbeitsteilig arbeiten - also nur die API zur 
Verfügung stellen/programmieren; so, dass sie Frontend-Programmierer 
einfach benutzen können. Ich stelle mir das dann so vor, dass das 
Frontend im header so ein Token wie oben generiert mitgibt, dass die Api 
lesen kann.

Aber wie stelle ich dann in der API fest, welcher Microsoft-Benutzer im 
Poken  ist, und ob das token gültig ist? Ich habe zwar auch da ein 
Beispiel gefunden, aber da wird ein "secret" zum Entschlüsseln des 
Tokens verwendet - wo bekomme ich das her (config.secret s.u.)? Soll das 
der API-Nutzer auch mitgeben?

aus https://www.bezkoder.com/node-js-mongodb-auth-jwt/

  jwt.verify(token, config.secret, (err, decoded) => {
    if (err) {
      return res.status(401).send({ message: "Unauthorized!" });
    }
    req.userId = decoded.id;
    next();
  });

[Joachim S. (oyo)]

Aua schrieb:
> Aber wie stelle ich dann in der API fest, welcher Microsoft-Benutzer im
> Poken  ist, und ob das token gültig ist? Ich habe zwar auch da ein
> Beispiel gefunden, aber da wird ein "secret" zum Entschlüsseln des
> Tokens verwendet - wo bekomme ich das her (config.secret s.u.)? Soll das
> der API-Nutzer auch mitgeben?

Meinem (allerdings nur oberflächlichen) Verständnis nach ist so ein 
JWT-Token im Wesentlichen einfach ein digital signiertes JSON-Objekt, 
und das besagte "secret" ist einfach ein letztlich beliebiger String, 
der als kryptographischer Schlüssel zum Signieren/Verifizieren dient, 
eine Art "private key". Also z.B. eine etwas längere, zufällig 
generierte Zeichenfolge, die nur Dir bekannt ist.

Du legst ein beliebiges JSON-Objekt an, das die für Dich relevanten 
Daten enthält, bspw. eben die ID des Microsoft-Benutzers. Dann signierst 
Du diese Daten per JWT.sign(), heraus kommt eine längere Zeichenkette, 
das eigentliche JWT-Token. Dieses Token übergibst Du Deinen API-Nutzern, 
wenn sie Deine API nutzen, schicken sie im Request dieses Token mit.
Per JWT.verify() überprüfst Du dann das Token - wenn die Verifizierung 
erfolgreich ist, dann weisst Du, dass es ein gültiges Token ist, das von 
Dir selbst per JWT.sign() erstellt wurde, und Du den darin enthaltenen 
und von der JWT.verify() zurückgegebenen Daten vertrauen kannst. Etwas 
übervereinfacht gesagt erhältst Du als Ergebnis der JWT.verify() einfach 
das gleiche von Dir selbst festgelegt JSON-Objekt zurück, das Du vorher 
der JWT.sign()-Funktion übergeben hast.

[Aua (Gast)]

So hatte ich es auch verstanden, aber das Token erhalte ich ja von 
Microsoft, wie s.o. beschrieben, generiere es also nicht selbst. Wie 
bekomme ich dann das Secret zum Entschlüsseln?

[Joachim S. (oyo)]

Aua schrieb:
> So hatte ich es auch verstanden, aber das Token erhalte ich ja von
> Microsoft, wie s.o. beschrieben, generiere es also nicht selbst. Wie
> bekomme ich dann das Secret zum Entschlüsseln?

Achso, sorry, das war mich nicht klar. Den Anfang Deines Postings hatte 
ich im Grunde schlicht ignoriert, weil ich ihn nicht wirklich verstanden 
habe (also um was es eigentlich überhaupt geht, was das mit Microsoft zu 
tun hat etc.)

[Aua (Gast)]

Also worum es geht: Es soll eine Single Page-Anwendung entwickelt 
werden. Damit man darin keine User anlegen und administrieren muss, soll 
Single-Sign-on mit Microsoft verwendet werden, weil alle potentiellen 
Anwender schon einen Microsoft -Account haben.

Es gibt 2 getrennte Entwickler"gruppen": Frontend und API. Die 
Frontend-Leute holen ein Token s.o. und bauen eine App, die das Token an 
die API gibt (im Header).

Die API - Entwickler: Woher bekommen sie das "secret", um das Token zu 
entschlüsseln?

[Hannes J. (Firma: _⌨_) (pnuebergang)]

Aua schrieb:
> Die API - Entwickler: Woher bekommen sie das "secret", um das Token zu
> entschlüsseln?

Entschlüsseln? Ich dachte eigentlich es wird nur verifiziert ob das 
Token gültig ist. Wenn ich mit dem Key für Benutzer X sein Token 
verifizieren kann, dann weiß ich ja, dass es das von Benutzer X ist. 
Dann muss ich es nicht komplett entschlüsseln um darin den String 
"Benutzer X" zu finden.

Egal ...

Wenn Microsoft nicht was komplett eigenes gestrickt hat, dann fragst du 
in deiner Anwendung den Schlüssel von einem Identity Provider ab. Das 
ist die Cloud-Komponente, bei der sich der Benutzer auch einmalig 
angemeldet hat.

Soweit ich weiß (nie selber programmiert), ist Microsofts Cloud Identity 
Provider eine Komponente namens Azure AD. Danach würde ich mal googeln.

[Aua (Gast)]

Hannes J. schrieb:
> Entschlüsseln? Ich dachte eigentlich es wird nur verifiziert ob das
> Token gültig ist. Wenn ich mit dem Key für Benutzer X sein Token
> verifizieren kann, dann weiß ich ja, dass es das von Benutzer X ist.

Aber woher weiß die API dann, dass es Benutzer X ist, wenn sie doch nur 
einen verschlüsstelten String (das Token) erhält?

[Nico T. (wurstnase)]

Häufig ist es ein base64 codiertes JWT (Json Web Token). Das besteht aus 
drei Sektionen die mit einem Punkt getrennt sind. Im ersten Teil ist die 
Information wie das Token signiert wurde. Im zweiten Teil sind je nach 
Token-Art auch Informationen vom User mit dabei, bzw. nur die 
Berechtigungen, wann das Token ausgestellt wurde und auch wie lange es 
gültig ist. Im letzten Teil ist die Signatur.


Die Idee dahinter ist, dass man prüft, dass die Signatur gültig ist, das 
Token vom richtigen Endpunkt kommt und das es noch (oder schon) gültig 
ist. Stateless.


Auf jwt.io und auth0 sind so die ersten Anlaufstellen um das ganze zu 
verstehen.