it-swarm.com.de

Verwenden von JWT zum Implementieren der Authentifizierung in der Asp.net-Web-API

Ich habe über JWT gelesen.

Aber nach dem, was ich gelesen habe, handelt es sich nicht um einen Authentifizierungsmechanismus, sondern eher um eine entscheidende Komponente in einem Authentifizierungsmechanismus.

Ich habe momentan eine Lösung implementiert, die funktioniert, aber es war nur, JWT auszuprobieren und zu sehen, wie es funktioniert. Aber was ich jetzt will, ist, wie man davon Gebrauch machen soll. Nach meiner Erfahrung handelt es sich im Grunde genommen nur um einen Verschlüsselungsmechanismus, mit dem Sie einen eindeutigen verschlüsselten Schlüssel erhalten. Sie können auch Informationen in dieses Token einfügen.

Ich möchte es in Bezug auf eine ASP.NET-Web-API 2 implementieren, die von einer mobilen Anwendung verwendet werden soll.

Also Schritt 1:

  1. app => Server: Login (Benutzer, Passwort)
  2. Server => App: Login OK, hier ist dein JWT
  3. app => server: Mein Profil abrufen (sendet JWT mit Anfrage) Der Server entschlüsselt dann JWT und ermittelt die Identität der Anfragen.

Das ist nur mein Verständnis davon. Schau, ich könnte auf dem völlig falschen Weg sein.

Ist das Ideal von JWT so, dass Sie sich nicht bei jeder Anfrage authentifizieren müssen? Ich authentifiziere die Benutzeranmeldeinformationen nur einmal (bei der ersten Anmeldung) und dann, nachdem der Server einfach JWT verwenden kann und nicht die Benutzer pw und user in der DB nachschlagen muss?

Ich möchte nur das JWT verwenden, um zu identifizieren, wer der Benutzer ist. Ich werde dann autorisieren, nachdem ich sie authentifiziert habe. Wie ich weiß, gibt es eine große Verwirrung mit der neuen MVC und Authentifizierung und Autorisierung.

Also worauf meine Frage hinausläuft.

Wie kann ich einen Authentifizierungsmechanismus mithilfe von JWT sicher und effektiv implementieren? Ich möchte nicht nur etwas ausspucken, das zu funktionieren scheint und keine Ahnung von den Auswirkungen auf die Sicherheit hat. Ich bin sicher, dass es eine Quelle gibt, in der möglicherweise ein sicherer Mechanismus entwickelt wurde, der meinen Anforderungen entspricht.

Meine Anforderungen sind:

  • Müssen Sie db für Benutzeranmeldeinformationen nur einmal pro Sitzung überprüfen? Durch die Verwendung von bcrypt werden viele Ressourcen zum Vergleichen von Passwörtern benötigt.
  • Muss in der Lage sein, den Benutzer anhand seiner Anfrage zu identifizieren. (Dh wer sie sind, userId wird ausreichen) und vorzugsweise auch ohne Zugriff auf die DB
  • Sollte so wenig Aufwand wie möglich verursachen, was die Ressourcen auf der Serverseite anbelangt, die die Anforderung verarbeiten.
  • Wenn ein Eindringling zuvor eine Geräteanforderung kopieren musste, sollte er nicht auf die Daten des tatsächlichen Benutzers zugreifen können. (offensichtlich)

Vielen Dank

56
Zapnologica

Ihr Verständnis von JWTs ist gut. Aber hier sind ein paar Korrekturen und einige Empfehlungen.

Authentifizierung und Autorisierung

  • JWTs haben nichts mit Authentifizierung zu tun. Wenn Sie sich beim Erstellen des JWT authentifizieren, treffen Sie nur auf Ihre DB und Hashing-Kennwörter. Dies ist orthogonal zu JWTs und Sie können dies nach Belieben tun. Ich persönlich mag Membership Reboot , das auch ein gutes Beispiel für die Verwendung von JWTs enthält.
  • Theoretisch könnte der Benutzer einmal im Jahr ein Passwort eingeben und die JWT für das gesamte Jahr gültig sein. Dies ist höchstwahrscheinlich nicht die beste Lösung, wenn die JWT zu irgendeinem Zeitpunkt gestohlen wird und die Ressourcen des Benutzers beeinträchtigt werden.

Verschlüsselung

  • Token können, müssen aber nicht verschlüsselt werden. Das Verschlüsseln Ihrer Token erhöht die Komplexität Ihres Systems und den Rechenaufwand, den Ihr Server zum Lesen der JWTs benötigt. Dies kann wichtig sein, wenn Sie verlangen, dass niemand das Token im Ruhezustand lesen kann.
  • Token werden vom Aussteller immer kryptografisch signiert, um ihre Integrität sicherzustellen. Das heißt, sie können weder vom Benutzer noch von Dritten manipuliert werden.

Ansprüche

Ihre JWTs können beliebige Informationen enthalten. Der Benutzername, das Geburtsdatum, die E-Mail-Adresse usw. Dies erfolgt mit anspruchsbasierter Berechtigung. Dann teilen Sie Ihrem Provider einfach mit, dass er eine JWT mit diesen Ansprüchen aus dem Anspruchsprinzip erstellen soll. Der folgende Code stammt aus diesem Beispiel für einen Neustart der Mitgliedschaft und zeigt Ihnen, wie dies getan wird.

public override Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context)
{
    var svc = context.OwinContext.Environment.GetUserAccountService<UserAccount>();
    UserAccount user;
    if (svc.Authenticate("users", context.UserName, context.Password, out user))
    {
        var claims = user.GetAllClaims();

        var id = new System.Security.Claims.ClaimsIdentity(claims, "MembershipReboot");
        context.Validated(id);
    }

    return base.GrantResourceOwnerCredentials(context);
}

Auf diese Weise können Sie genau steuern, wer auf Ihre Ressourcen zugreift, ohne den prozessorintensiven Authentifizierungsservice zu beeinträchtigen.

Implementierung

Eine sehr einfache Möglichkeit, einen Token-Provider zu implementieren, ist die Verwendung von Microsoft OAuth Authorization Server in Ihrem WebAPI-Projekt OAuth Server für Ihre API.

Sie könnten auch in Thinktecture's Identity Server nachschauen, was Ihnen die Kontrolle über Benutzer erheblich erleichtern würde. Beispielsweise können Sie Aktualisierungs-Token auf einfache Weise mit einem Identity Server implementieren, bei dem der Benutzer einmal authentifiziert wird und dann für einen bestimmten Zeitraum (möglicherweise einen Monat) kurzlebige JWTs vom Identity Server abrufen kann. Die Aktualisierungstoken sind gut, da sie widerrufen werden können, JWTs dagegen nicht. Der Nachteil dieser Lösung ist, dass Sie einen oder zwei weitere Server einrichten müssen, um den Identitätsdienst zu hosten.

Um mit Ihrem letzten Punkt fertig zu werden, dass ein Eindringling nicht in der Lage sein sollte, die letzte Anforderung zu kopieren, um Zugriff auf eine Ressource zu erhalten, Sie müssen mindestens SSL verwenden. Dies schützt das Token in Transport.

Wenn Sie etwas extrem empfindliches schützen, sollten Sie die Lebensdauer des Tokens auf ein sehr kurzes Zeitfenster beschränken. Wenn Sie etwas weniger empfindliches schützen, können Sie die Lebensdauer verlängern. Je länger das Token gültig ist, desto länger muss ein Angreifer die Identität des authentifizierten Benutzers annehmen, wenn der Computer des Benutzers gefährdet ist.

55
Thomas Sobieck

Ich habe einen ausführlichen Blogbeitrag über die Konfiguration des OWIN-Autorisierungsservers geschrieben, um signierte JSON-Web-Tokens anstelle des Standardtokens auszustellen. Auf diese Weise können sich die Ressourcenserver (Zielgruppe) beim Autorisierungsserver registrieren und anschließend die vom Token-Aussteller ausgegebenen JWT-Token verwenden, ohne dass die machineKey-Werte zwischen allen Parteien vereinheitlicht werden müssen. Sie können den Beitrag lesen JSON-Web-Token in ASP.NET Web API 2 mit Owin

23
Taiseer Joudeh