2016-10-01 4 views
1

Ich entwickle ein j2ee Authentifizierungs-/Autorisierungssystem. Ich möchte JWT-Token verwenden, die Payload mit JWS signieren und sie mit JWE verschlüsseln.Wie erstelle ich ein JWT/JWS mit JWE

I found a decent tutorial from bitbuckets jose4j

Dieses Beispiel zeigt ihnen eine JWK mit EllipticCurveJsonWebKey zu erzeugen. Ich verstehe nicht, wie dies für die Authentifizierung/Autorisierung verwendet werden könnte. Müssten Sie nicht einen geheimen Schlüssel in einer Eigenschaftendatei oder einem JNDI-Eintrag speichern und dann diesen Schlüssel zum Signieren/Verschlüsseln der JWT verwenden? Auf diese Weise kann ich, wenn ich eine HTTP-Anfrage erhalte, denselben Schlüssel verwenden, um die JWT zu verifizieren. Die meisten Tutorials, die ich gefunden habe, verwenden ein ähnliches Beispiel.

Wie könnte dies mit dem gleichen serverseitigen geheimen Schlüssel geschehen?

+0

Versuchen Sie in Ihrer Implementierung OAuth2.0/OIDC-kompatibel zu sein, oder verwenden Sie nur JWTs (mit JWS und JWE), um eine Benutzersitzung zu führen? – ingenious

+0

@ingenious Ich möchte den Benutzern die Möglichkeit geben, sich mit OAuth2-Anbietern wie Google einzuloggen, aber das Hauptziel ist es, eine Benutzersitzung zu führen. –

Antwort

1

Erste Dinge zuerst - gehen Sie zur Kasse diesen Artikel über authentication with OAuth2.0. Abhängig von Ihrem Hintergrund müssen Sie möglicherweise etwas in OAuth & OpenID Connect selbst lesen.

Wenn Sie jedoch nur Ihre serverseitige Sitzung in einem signierten und verschlüsselten JWT behalten möchten, ist das auch OK. In Ihrem JWT finden Sie ein paar Ansprüche benötigen, zumindest einige angibt:

  • wenn wurde die Sitzung erstellt (IAT)
  • wie lange die Sitzung noch gültig (exp)
  • , die erstellt die Sitzung, das ist Ihr auth-System (iss)
  • , die von dieser Sitzung authentifiziert ist, das ist Ihr Benutzer-ID oder etwas (sub)

Später können Sie ein Publikum und vorzugsweise eine Nonce hinzuzufügen. Wenn Sie jedoch alles verschlüsseln, können Sie auch ohne Nonce damit zurechtkommen.

Es ist allgemein eine gute Idee, sich auf die vorgeschlagenen Ansprüche in the OIDC core spec zu beziehen.

Und hier wird es knifflig. Sie haben grundsätzlich zwei Optionen - Sie können entweder serverseitig eine Zeichenfolge generieren, die für alle Anwendungen vollständig undurchsichtig ist und die Sitzung wird. Dann bieten Sie einen Token-Introspektionsendpunkt an, an den Clients diese Zeichenfolge senden und die oben beschriebenen Ansprüche abrufen können (plus alle zusätzlichen, die Sie Ihrer Sitzung zuordnen möchten). Dies bedeutet auch, dass Sie Speicherplatz benötigen, wo diese undurchsichtigen Zeichenfolgen zusammen mit den Benutzeranfragen, denen sie zugeordnet sind, beibehalten werden.

Alternativ können Sie auch die gesamte Gruppe unterschreiben (und optional verschlüsseln) und über die Leitung senden. Sie müssen nur eine ID für das Token haben, nur wenn Sie sich abmelden können. Das Signieren des Tokens erfolgt mit einem privaten Schlüssel, den nur Ihre Anwendung kennt und der in jedem Client durch einen öffentlichen Schlüssel verifiziert wird, den Ihre Anwendung z. indem Sie einen JWKs-Endpunkt anbieten.

Je nachdem, welche Ansprüche Sie in Ihr JWT eingeben, brauchen Sie es vielleicht gar nicht zu verschlüsseln ... Wenn Sie das tun, dann müssen Sie die Schlüssel auch für die Verschlüsselung verwalten.

Überprüfen Sie auch this article für einen sehr guten Überblick über was ist, was in Token Auth.

+0

Sobald ich dachte, dass ich die ganze Sache in den Griff bekommen habe ... bist du mitgekommen und hast das blöd gemacht. Danke für die Information, es war sehr hilfreich. –