目前在我的网络服务中，我利用app.UseWindowsAzureActiveDirectoryBearerAuthentication来验证AAD发行的令牌及其真棒！我想为任何OpenId Connect令牌做类似的事情，但我不确定UseWindowsAzureActiveDirectoryBearerAuthentication是否是正确的，因为它特定于AAD并且它没有提及底层协议。似乎唯一的另外两个选项是app.UseJwtBeararAuthentication和app.UseOAuthBeararAuthentication。我将使用的身份提供者很可能支持发现，因此我们的想法是简单地注册有效的受众，发行者和发现或metada url，并让身份验证中间件处理剩下的事情（检索签名密钥，缓存它，验证过期，发行者，观众等）就像我使用UseWindowsAzureActiveDirectoryBearerAuthentication一样。这两个中间件中哪一个是推荐的？
答案 0 :(得分：0)
app.UseWindowsAzureActiveDirectoryBearerAuthentication和app。 UseJwtBearerAuthentication在内部调用UseOAuthBeararAuthentication中间件。前者用于xml，后者用于jwt令牌。我建议app.UseJwtBearerAuthentication符合您的要求。
答案 1 :(得分：0)
当您访问网络服务时，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。