Aspnetcore 身份验证关联失败

Question

我在 GIT 上搜索了不同的 SO 答案和 Aspnetcore 身份验证，但没有一个解决方案有帮助。我有一个“关联失败”的问题，原因是关联 cookie 没有被设置，即使它在重定向到谷歌的响应头中很明显。 在此处输入图片说明

这是 Fiddler 中的响应：

HTTP/1.1 302 找到位置： https //accounts.google.com/o/oauth2/v2/auth?response_type=code&client_id= Full2Full2Ahds.googleusercontent.com =的OpenID％20profile％20email＆状态= CfDJ8EGRdEf8M7VDtyNKY6R10TxxM2kHFoDlOBkCQKoMQJXX3QPKcyH8quz80oy8Wd7Rq1Nnb-KhklzrC-XK4WOhikAVtJuFHIk_M4ZvLY8Le2FkjVNxJrHDsZeg7o1sMrABd_md1jxi-LelhURiB54SUAHbaJciseDc5NP897CSsrtYoPt_IWyqNOdxCjPntxwHYUzO2ZxIcfSLaLGu8rWlfHTEqvj_N7KQ0k8HQ8VwPYDXjAMwjjsGRdxR6dOl-vNfzfOqX0wZelvVsX5UIfzMjlCJ20lQxLIhlkhkpne14EYYNkJufqF4ZADD13jvsj4qnw 服务器：Kestrel Set-Cookie：.AspNetCore.Correlation.Google.WKzW6d​​i96f3Fbh4ThkfIFHteUvNLusesaT0VjAMhrDU=N；到期=格林威治标准时间 2018 年 11 月 17 日星期六 16:14:20；路径=/登录-谷歌；安全的; 相同站点=严格；httponly Set-Cookie: .AspNetCore.Mvc.CookieTempDataProvider=; 到期=格林威治标准时间 1970 年 1 月 1 日星期四 00:00:00；路径=/；安全的; 相同站点=严格；httponly 日期：2018 年 12 月 28 日星期五 03:45:54 GMT 内容长度：0

我将数据保护设置为将密钥存储到一个位置，并且按预期工作。我的源代码管理在这里：https : //github.com/jjkesinger/charts/tree/master/Charts

有任何想法吗？本地机器上的 TLS 与它有什么关系吗？我可以将这个项目克隆到另一台机器上，它工作正常。它不工作的机器是 Windows 10 戴尔 experion

Answer 1

我也有这个问题，必须设置以下选项：

services.AddAuthentication().AddGoogle(g => 
{
   g.ClientId = XXXXXXX;
   g.ClientSecret = XXXXXX;
   g.CorrelationCookie.SameSite = SameSiteMode.Lax
}

最后一行是解决我的问题的方法。

Answer 2

尽管在您的情况下，真正的问题是您的 cookie 策略为samesite=strict，但此错误通常意味着REDIRECT_URI身份提供商的应用程序注册中定义的值与 中提供的值不相关（不匹配）options.CallbackPath。

我认为他们说“关联”而不是“匹配”，因为它不必是相同的字符串。在下面的示例中，我仅提供/signin-microsoft，因为这与两者相关http://localhost:5000/signin-microsoft，并且https://production-domain-name/app-path.../signin-microsoft两者均在 Azure 上的应用程序注册中定义。

.AddMicrosoftAccount(microsoftOptions =>
{
    microsoftOptions.ClientId = Configuration["Authentication:Microsoft:ClientId"];
    microsoftOptions.ClientSecret = Configuration["Authentication:Microsoft:ClientSecret"];
    // SET THIS TO CORRELATE WITH REDIRECT_URI THAT YOU  
    // DEFINED IN THE APP REGISTRATION AT THE APP PROVIDER
    microsoftOptions.CallbackPath = "/signin-microsoft"; 
})

尽管从技术上讲是合理的，但这是一条非常无用的异常消息。他们没有理由不说WRONG CALLBACK PATH Provider did not call back on the path specified in options.CallbackPath Ensure REDIRECT_URI in app registration at provider correlates to the value supplied in options.CallbackPath

所有示例都没有指定回调路径，因此很多人根本不会提供回调路径的可能性很高（也会导致此问题）。