AddTemporarySigningCredential vs AddSigningCredential in IdentityServer4

Question

Gemäß den Dokumenten verwendet IdentityServer ein asymmetrisches Schlüsselpaar, um JWTs zu signieren und zu validieren. Man könnte entweder AddTemporarySigningCredential() in der Konfiguration verwenden, die bei jedem Start einen neuen RSA erstellt, oder AddSigningCredential(..) mit einem RSA-Schlüssel oder einem Zertifikat verwenden.

Das Dokument erwähnt die temporäre Version ist nützlich für Entwicklungssituationen, aber es zeigt nicht, was der Nachteil davon ist, wenn es in einer Produktionsumgebung verwendet wird.

Ich habe eine Aspnetcore Web API, in der die Clients mit dem IdentityServer4 authentifiziert werden. Das System funktioniert im Moment mit dem temporaryigningcredential, aber ich frage mich, ob es einen Vorteil bei der Verwendung der anderen Variante gibt.

Danke,

Answer 1

Der Nachteil ist, dass jedes Mal, wenn IdentityServer, das Schlüsselmaterial neu starten wird sich ändern - oder IOW - alle Token, die mit dem vorherigen Schlüsselmaterial unterzeichnet wurden, werden zur Validierung fehl.

"Temporär" ist wirklich nur für Situationen, in denen Sie kein anderes Schlüsselmaterial zur Verfügung haben.

Answer 2

Statt AddTemporarySigningCredential betrachten AddDeveloperSigningCredential

Von http://docs.identityserver.io/en/release/topics/startup.html#refstartupkeymaterial zu verwenden:

AddDeveloperSigningCredential

gleichen Zweck wie die temporäre Unterzeichnung Berechtigungsnachweis. Aber diese Version beharrt den Schlüssel zum Dateisystem, so dass es stabil bleibt zwischen Server Neustarts. Dies behebt Probleme, wenn die clients/api-Metadaten-Caches während der Entwicklung nicht mehr synchron sind.

WARNUNG: AddDeveloperSigningCredential kann nur verwendet werden, wenn IdentityServer Host auf einem SINGLE Maschine läuft, für Produktionsfarm benötigen Sie AddSigningCredential verwenden.