web-dev-qa-db-fra.com

L'obtention de DiscoveryClient échoue avec «le nom de l'émetteur ne correspond pas à l'autorité»

J'obtiens l'erreur ci-dessous lors de l'exécution d'un GET en utilisant DiscoveryClient d'IdentityModel comme suit:

var discoveryResponse = await DiscoveryClient.GetAsync("https://localhost/IdentityServer");

Le nom de l'émetteur ne correspond pas à l'autorité: https: // localhost/identityserver

L'URL cible est une application Web ASP.NET Core exécutée sur IIS activé avec IdentityServer4. L'application cliente est une application Web ASP.NET classique exécutée sur la même machine.

Apparemment, le GET a réussi à récupérer les valeurs de IdentityServer comme en témoigne le contenu de discoveryResponse.Raw:

{
  "issuer": "https://localhost/identityserver",
  "jwks_uri": "https://localhost/IdentityServer/.well-known/openid-configuration/jwks",
  "authorization_endpoint": "https://localhost/IdentityServer/connect/authorize",
  "token_endpoint": "https://localhost/IdentityServer/connect/token",
  "userinfo_endpoint": "https://localhost/IdentityServer/connect/userinfo",
  "end_session_endpoint": "https://localhost/IdentityServer/connect/endsession",
  "check_session_iframe": "https://localhost/IdentityServer/connect/checksession",
  "revocation_endpoint": "https://localhost/IdentityServer/connect/revocation",
  "introspection_endpoint": "https://localhost/IdentityServer/connect/introspect",
  "frontchannel_logout_supported": true,
  "frontchannel_logout_session_supported": true,
  "scopes_supported": [ "CustomIdentityResources", "profile", "openid", "MyAPI.full_access", "offline_access" ],
  "claims_supported": [],
  "grant_types_supported": [ "authorization_code", "client_credentials", "refresh_token", "implicit" ],
  "response_types_supported": [ "code", "token", "id_token", "id_token token", "code id_token", "code token", "code id_token token" ],
  "response_modes_supported": [ "form_post", "query", "fragment" ],
  "token_endpoint_auth_methods_supported": [ "client_secret_basic", "client_secret_post" ],
  "subject_types_supported": [ "public" ],
  "id_token_signing_alg_values_supported": [ "RS256" ],
  "code_challenge_methods_supported": [ "plain", "S256" ]
}
asp.netasp.net-coreidentityserver4
14
Sigurd Garshol

autorité: https: // localhost/IdentityServer émetteur: https: // localhost/identityserver

Ils ne correspondent pas - il est sensible à la casse.

18
leastprivilege

Dans le cas où vous ne pouvez pas modifier le code du serveur pour l'adapter à la stratégie, vous pouvez modifier les paramètres de stratégie pour autoriser les incohérences de noms.

Par exemple, j'essaie d'utiliser DiscoveryClient sur l'API Azure Rest, et le issuer est https://sts.windows.net/{{ tenant_id }} tandis que tous les points finaux commencent par https://login.Microsoft.com/{{ tenant_id }}.

Définissez simplement les champs ValidateIssuerName et ValidateEndpoints sur false.

var tenant_id = "8481D2AC-893F-4454-8A3B-A0297D301278"; // Made up for this example
var authority = $"https://login.microsoftonline.com/{tenant_id}";
DiscoveryClient discoveryClient = new DiscoveryClient(authority);

// Accept the configuration even if the issuer and endpoints don't match
discoveryClient.Policy.ValidateIssuerName = false;
discoveryClient.Policy.ValidateEndpoints = false;

var discoResponse = await discoveryClient.GetAsync();
3
Andrew Shepherd