AddTemporarySigningCredential im Vergleich zu AddSigningCredential in IdentityServer4

8

Laut 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.

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,

    
cellik 10.01.2017, 15:53
quelle

2 Antworten

14

Der Nachteil ist, dass bei jedem Neustart von IdentityServer das Schlüsselmaterial geändert wird - oder IOW - alle Token, die mit dem vorherigen Schlüsselmaterial signiert wurden, können nicht validiert werden.

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

    
leastprivilege 10.01.2017, 19:57
quelle
10
___ qstnhdr ___ AddTemporarySigningCredential im Vergleich zu AddSigningCredential in IdentityServer4 ___ qstntxt ___

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

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,

    
___ antwort43962692 ___

Anstelle von AddTemporarySigningCredential sollten Sie AddDeveloperSigningCredential

verwenden

Aus Ссылка :

AddDeveloperSigningCredential

  

Derselbe Zweck wie die temporäre Signaturberechtigung. Aber diese Version   hält den Schlüssel zum Dateisystem aufrecht, so dass es zwischen den Servern stabil bleibt   startet neu. Dies behebt Probleme, wenn die Client / API-Metadaten zwischenspeichert   während der Entwicklung nicht mehr synchron laufen.

WARNUNG: AddDeveloperSigningCredential kann nur verwendet werden, wenn der IdentityServer-Host auf einem EINZIGEN Computer läuft. Für die Produktionsfarm müssen Sie AddSigningCredential verwenden.

    
___ answer41577304 ___

Der Nachteil ist, dass bei jedem Neustart von IdentityServer das Schlüsselmaterial geändert wird - oder IOW - alle Token, die mit dem vorherigen Schlüsselmaterial signiert wurden, können nicht validiert werden.

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

    
___
Michael Freidgeim 14.05.2017 10:07
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset primeNG p-dropdown strecken 100%