OWIN OpenIdConnect Middleware IDX10311 nonce ne peut pas être validé
J'ai une application utilisant le middleware OWIN pour OpenIdConnect. Le fichier startup.cs utilise l'implémentation standard d'app.UseOpenIdConnectAuthentication. Le cookie est défini sur le navigateur, mais il contient une erreur avec:
IDX10311: RequireNonce est 'true' (valeur par défaut) mais validationContext.Nonce est null. Un nonce ne peut pas être validé. Si vous n'avez pas besoin de vérifier le nonce, définissez OpenIdConnectProtocolValidator.RequireNonce sur 'false'.
J'ai constaté que lors de l'exécution de fiddler, comme c'est le cas pour la plupart des projets de débogage, ce problème se produit. L'erreur est renvoyée, mais si je retourne sur le site, tout fonctionne et mon utilisateur est authentifié. Quelqu'un at-il vu ce comportement lors de l'exécution de violoneux?
Avec violoneux:
- La notification SecurityTokenValidated dans OpenIdConnect est exécutée deux fois.
- Après la deuxième passe, l'erreur IDX10311 est renvoyée.
- Le navigateur contient le cookie valide, en revenant à la page, je peux afficher les données User.Identity valides.
Courir sans violoneux:
- SecurityTokenValidated s'exécute une fois dans OpenIdConnect
- Aucune erreur renvoyée, charge l'action du contrôleur pour la redirection post-authentification Uri
- Cookie également valide et données User.Identity correctes.
Des idées? Je peux contourner le problème sans lancer de violoniste, mais lors du débogage, il serait bien de lancer également le violoneur pour inspecter le trafic.
J'ai eu le même problème, mais le retour du Microsoft.Owin.Security.OpenIdConnect à la version 3.0.1 a résolu le problème.
Peut-être est-ce la cause?
Bonjour, je pense avoir trouvé la cause première de ce problème.
Je résume mes découvertes:
Le problème est dans le cookie OpenIdConnect.nonce.OpenIdConnect
Ce cookie est défini depuis l'application (appelons ce "ID Client") dès que le Middleware OpenID initie une session d'authentification.
Le cookie doit être renvoyé du navigateur vers le "client ID" dès que l'authentification est terminée. Mon hypothèse est que ce cookie est nécessaire pour une double vérification du point de vue du client ID (c'est-à-dire, ai-je vraiment démarré un flux d'autorisation OpenID Connect?)
Le terme "Nonce", utilisé à la fois dans ce cookie et dans le flux OpenID Connect à partir du serveur d'ID, a provoqué beaucoup de confusion.
L'exception, dans mon cas, a été provoquée par le cookie manquant (et non par le nonce de l'ID Server), simplement parce qu'il n'a pas été renvoyé par le navigateur au "client ID".
Ainsi, la racine principale, dans mon cas, était la suivante: le cookie OpenIdConnect.nonce.OpenIdConnect n'a pas été renvoyé à l'ID Client par le navigateur. Dans certains cas (comme Chrome, Firefox et Edge), le cookie a été envoyé correctement, alors que dans d’autres (IE11, Safari), il ne l’a pas été.
Après de nombreuses recherches, j'ai découvert que le problème était lié à la stratégie de restriction des cookies définie dans le navigateur. Dans mon cas, le "client ID" est incorporé dans un <iframe>. Cela fait en sorte que le "client ID" soit considéré comme un "client tiers", car l'utilisateur ne s'est pas dirigé directement vers cette URL dans la fenêtre principale. Comme il s'agit d'un tiers, il est nécessaire de bloquer les cookies pour certains navigateurs . En effet, le même effet peut être obtenu sur Chrome en définissant l'option "Bloquer les cookies tiers".
Donc, je dois conclure que:
a) Si l'iframe est indispensable (comme dans mon cas, car les "clients ID" sont des applications qui doivent s'exécuter dans le contenu graphique de notre application de plate-forme principale), je pense que la seule solution consiste à intercepter l'erreur et à la gérer. une page, demandant à l'utilisateur d'activer les cookies tiers.
b) Si iframe n'est pas indispensable, il suffit d'ouvrir le "ID Client" dans une nouvelle fenêtre.
J'espère que cela aide quelqu'un, parce que je suis devenu fou!
Marco
Je sais que c’est un vieil article, mais j’avais ce problème et que rien ne fonctionnait pour moi. Après avoir perdu l’esprit derrière une solution permettant de faire fonctionner mon application d’entreprise, je règle le problème en définissant l’option multi-locataire sur yes dans Azure (dans Azure sélectionnez: enregistrement de l'application> paramètres> propriétés, définissez la propriété à locataires multiples sur Oui, puis cliquez sur Enregistrer).
j'espère que ça aide quelqu'un, je ne pouvais voir personne le mentionner.
Pour moi, le changement d'URL de réponse dans Azure Active Directory fonctionne.
Cela se produit lorsque vous activez SSL, car il ne modifie que l'URL de connexion en URL HTTPS, tandis que l'URL de réponse reste la même URL HTTP.
Lorsque vous essayez d'accéder à votre application à l'aide de l'URL https, un cookie avec un numéro unique (nonce) est créé dans votre navigateur et il est authentifié par Azure AD. Après l’authentification, le navigateur doit donner accès à ce cookie. Mais étant donné que l'URL de connexion et l'URL de réponse sont différentes, le navigateur ne reconnaît pas votre application et ne donne pas accès à ce cookie. L'application génère donc cette erreur.
Une solution temporaire qui fonctionnait pour moi pour une application sécurisée via Azure Active Directory consistait à vous déconnecter (en accédant à la page sites/Compte/SignOut), puis à retourner à la page d'accueil et à vous connecter correctement. J'espère que ça aide quelqu'un.
J'ai remarqué cette erreur lors de l'exécution de IIS Express en arrière-plan lorsque je suis passé à l'hébergement en version complète d'IIS. Lorsque j'ai désactivé le IIS Express, mon erreur a disparu.
Une règle de réécriture des cookies dans le fichier web.config pour garantir que les cookies du même site transmettent cette exception cryptique Désactiver cette règle a résolu le problème.