目前，在我的 Web 服务中，我利用 app.UseWindowsAzureActiveDirectoryBearerAuthentication 来验证 AAD 颁发的令牌及其真棒！我想对任何 OpenId Connect 令牌执行类似的操作，但我不确定 UseWindowsAzureActiveDirectoryBearerAuthentication 是否正确，因为它特定于 AAD 并且它没有说明底层协议。似乎只有另外两个选项是 app.UseJwtBeararAuthentication 和 app.UseOAuthBeararAuthentication。我将使用的身份提供者很可能支持发现，因此想法是简单地注册有效的受众、颁发者和发现或元数据 url，并让身份验证中间件处理其余部分（检索签名密钥，缓存它，验证过期，发行者、受众等），就像我对 UseWindowsAzureActiveDirectoryBearerAuthentication 所做的那样。
问问题
663 次
2 回答
0
app.UseWindowsAzureActiveDirectoryBearerAuthentication 和 app.UseWindowsAzureActiveDirectoryBearerAuthentication 都适用。UseJwtBearerAuthentication 在内部调用 UseOAuthBeararAuthentication 中间件。前者用于 xml，后者用于 jwt 令牌。我会推荐 app.UseJwtBearerAuthentication 满足您的要求。
于 2015-03-25T06:25:17.650 回答
0
当您访问 Web 服务时，OpenID Connect 并没有真正添加任何魔法酱，它或多或少与 OAuth2 相同。为此，您继续使用“OAuth 2.0 授权框架：承载令牌使用”，RFC 6750。发送到 Web API 的令牌是访问令牌，即使在 OpenID Connect 中也保持不透明。您描述的机器是id_tokens，它们都是通过依赖于通过浏览器交付的应用程序的授权获得的（因此不是 Web 服务，而是为 UX 或本机客户端提供服务的 Web 应用程序）。在 Web 服务的情况下，客户端不一定是 Web 浏览器，这就是为什么您通常坚持使用 RFC 6750 来访问它的原因。现在：Azure AD 碰巧对 id_token 和访问令牌使用相同的令牌格式和相同的签名密钥，这可能就是您认为该方法可以通用的原因 - 但没有规范要求任何关于访问令牌的内容，因此它是不推广到其他提供商的方法 - 用于 Web 服务/API。它适用于 Web UX。
于 2015-03-25T08:18:20.243 回答