Ich versuche, IdentityServer3 für die Autorisierung in einer .NET-Webanwendung zu beschleunigen.Warum wird ein Signierungszertifikat für den Impliziten Nachrichtenfluss in IdentityServer3 benötigt, nicht jedoch für die Flüsse ClientCredential und ResourceOwner?
Ich versuche herauszufinden, warum der Implizite Fluss erfordert, dass IdentityServer ein Signaturzertifikat haben, während die Autorisierungsflüsse dies nicht erfordern.
So weit verstehe ich: Die Flows "ClientCredential" und "ResourceOwner" sind "AuthorizationFlow" - dh sie haben ein Clientgeheimnis, alle Tokens werden vom Token-Endpunkt zurückgegeben, langlebige Authentifizierung über Refresh-Token Möglich ist, dass Token dem User-Agent/Browser nicht offengelegt werden (sie werden vielmehr auf dem Server gespeichert und ein Cookie oder ähnliches wird an den User-Agent/Browser gesendet) per https://www.scottbrady91.com/OpenID-Connect/OpenID-Connect-Flows. Für eine SPA/JS-Anwendung, die direkt auf eine WebAPI zugreift, sollte stattdessen Implicit Flow verwendet werden, da der JS-Client den Identity Server direkt vom Browser aufruft. Daher kann kein Clientgeheimnis erhalten werden (da es übertragen werden müsste) zum Browser, wodurch die Sicherheit gefährdet wird).
All das macht Sinn, aber in jedem Fall generiert der IdentityServer Token, die die Anwendung für die Autorisierung verwendet, weshalb ich verwirrt bin, warum sie in einem Fall signiert werden müssen, aber nicht in dem anderen?
Vielen Dank für Ihre Hilfe!
Vielen Dank! Ich bin immer noch ein wenig verwirrt, da ich davon ausgehe, dass alle drei Flüsse dem Aufrufer erlauben, ein Zugriffs-Token zu erhalten ... Ist dieses Token ein JWT für den Implicit-Fluss und ein anderer Tokentyp für die ClientCredentials- und ResourceOwner-Flüsse? Wenn ja, warum die verschiedenen Arten von Token für die verschiedenen Flüsse? – user756366