Worin besteht in IdentityServer3 der Unterschied zwischen Client Secrets und Scope Secrets?

Question

Kann jemand bitte erklären, was der Unterschied zwischen den beiden ist? Ich verstehe Client Secrets, aber Scope Secrets sind immer noch nicht klar ... und warum muss ein Scope Secret überhaupt existieren?

Während ich die documentation hilfreich in gewisser Weise gefunden, habe ich nicht finden es hilfreich, in den Unterschied zwischen den beiden zu erklären.

Answer 1

sind Client-Secrets verwendet Zugang zum token endpoint zu genehmigen. Dieser Endpunkt verwendet eine Client-ID und einen Client-Schlüssel und ermöglicht die Anforderung von Zugriffstoken.

werden Scope Secrets verwendet Zugang zum introspection endpoint zu genehmigen. Dieser Endpunkt verwendet eine Bereichs-ID und einen Bereichsschlüssel, da nur Bereiche, die in einem Zugriffstoken enthalten sind, diese prüfen dürfen.

Answer 2

Mit Dank an Scott Brady konnte ich meine Frage beantworten. Hier ist, was habe ich herausgefunden ...

Kunde Secrets

Wie Scott Brady sagte, Client-Secrets verwendet werden, wenn der Client-Anwendung die token end point aufruft. Auf diese Weise können nur autorisierte Client-Anwendungen auf den Endpunkt zugreifen. Ihre Clientanwendung muss über eine gültige Client-ID und einen geheimen Clientschlüssel verfügen, um den Token-Endpunkt aufzurufen.

Scope Secrets

Aber was, wenn Ihre Ressource-Server muss IdentityServer anrufen? Dies geschieht, wenn der access token end point vom Ressourcenserver aufgerufen wird. Dies tritt auf, wenn Ihre Anwendung Referenztoken verwendet (dies muss durch Aufrufen des Endpunkts des Zugriffstokens überprüft werden) ODER Sie haben entschieden, dass JWTs durch den Validierungsendpunkt validiert werden. Angenommen, Ihr authentifizierter Client ruft einen geschützten Endpunkt auf dem Ressourcenserver an. Der Ressourcenserver muss dann dieses Token mit dem Authentifizierungsserver (der von Ihnen verwendeten IdentityServer-Implementierung) validieren. Die Anforderung, die von Ihrem Ressourcenserver an Ihren Authentifizierungsserver gesendet wird, muss jedoch über Authentifizierungsinformationen verfügen. Es wäre töricht (und würde das Protokoll verletzen), wenn Ihr Ressourcenserver das gleiche Zugriffstoken verwendet, das er als Authentifizierungsmethode mit dem Authentifizierungsserver zu validieren versuchte. Jetzt gibt es ein Problem ... Wie kann der Ressourcenserver Authentifizierungsinformationen mit der Validierungsanforderung senden? Dies ist

wo Scope Secrets kommen. Die Art und Weise IdentityServer dieses Problem gelöst hat, sind Ihnen zu erlauben, einen Bereich zu schaffen, die ein Scope Geheimnis enthält. Dieser Bereich wird in Ihren Ressourcenserver-Authentifizierungsoptionen hinzugefügt. Beispiel:

app.UseIdentityServerBearerTokenAuthentication(
       new IdentityServerBearerTokenAuthenticationOptions 
       { 
        Authority = "http://localhost:5000", 
        ClientId = "api", //The Scope name 
        ClientSecret = "api-secret", //This is the non hashed/encrypted Scope Secret 
        RequiredScopes = new[] { "api" } //Must add the Scope name here since it has to be required 
       }); 

Durch die Angabe dieses Umfangs wird sichergestellt, dass jede authentifizierte Client-Anwendung diesen Umfang aufweist. Dann in IdentityServer würden Sie den Umfang wie so hinzufügen:

new Scope 
    { 
     Name = "api", 
     DisplayName = "Scope DisplayName", 
     Description = "This will grant you access to the API", 

     //The secret here must be Sha256-ed in order for the /introspection end point to work. 
     //If the API's IdentityServerBearerTokenAuthenticationOptions field is set as so ValidationMode = ValidationMode.ValidationEndpoint, 
     //then the API will call the /introspection end point to validate the token on each request (instead of ValidationModel.ValidationLocal. 
     //The ClientSecret must be the NON Sha256-ed string (for example Api = "api-secret" then scope secret must = "spi-secret".Sha256()) 
     //for the token to be validated. There must be a Scope that has the same name as the ClientId field in IdentityServerBearerTokenAuthenticationOptions. 
     //This is an API authenticates with IdentityServer 
     ScopeSecrets = new List<Secret> 
         { 
           new Secret("api-secret".Sha256()) 
         }, 
      Type = ScopeType.Resource 
     } 

So, wenn der Ressource-Server den Anruf an den Token-Validierung Endpunkt macht es einfach das Scope Geheimnis als das Client-Geheimnis verwenden und den Scope Namen als Client Ich würde.