我试图从概念上和实际上理解如何使用Azure AD在我的web-api应用程序中使用openID-connect流执行oauth2。
重要的是，当向API发出请求时，我想知道谁发出了请求。
我目前的理解是： -
这对我来说是个黑暗的地方。
我如何使用此令牌授权访问特定资源，确定访问资源的人员以及执行此操作的机制是什么？
我有点假设我需要重用令牌来调用Azure AD用户端点 - 如果令牌确实有效，AD端点将返回用户详细信息 - 从而提供一些确定方法令牌有效并提供有关用户身份的详细信息。授权访问资源可以通过Azure AD中的组成员身份来完成。
但是......
我只能假设这是一个已解决的问题，并注意到根据此示例使用OWIN中间件
https://github.com/AzureADSamples/WebApp-WebAPI-OpenIDConnect-DotNet
但我仍然不确定究竟发生了什么。
该服务提到范围和声明，但我不明白这些是从哪里派生的（我假设从客户提供的令牌，但不确定）。该服务必须在呼叫中接收身份信息。
这让我有两点意见，因为这是安全的 -
调用服务时提供的令牌需要在传输中保护（因此使用HTTPS） - 以防止MITM。
令牌需要签署一些方法 - 我猜通过使用客户机密码或其他东西 - 来防止令牌中的信息被欺骗。
有人可以帮我清理这个糊涂的混乱吗？
特别是 -
如何确定API调用者的身份 - 是通过客户端或服务器中的调用确定的身份？
如何根据用户角色限制对API某些端点的访问？
如何通过构建可用的现有中间件和库来实现这一目标？
答案 0 :(得分：6)
免责声明：这不是一个全面的答案。这是我的头脑。
OpenID Connect在OAuth之上提供身份层。在您的情况下，Active Directory 提供身份验证并发回access_token。访问令牌表示AD已通过身份验证的用户。如果您正在进行OpenID Connect，那么AD也会发送id_token，其中可能包含其他身份信息（例如生日，头像以及AD公开的任何其他信息。）
OpenID Connect和Active Directory都与您的应用分配给用户的角色无关;角色完全是你的应用程序的bailiwick。您可以像平常一样分配用户角色;您将它们分配给nameid，而不是电子邮件地址或用户名。您的应用不再需要对用户进行身份验证，但需要将角色分配给nameid。
如何确定API调用者的身份 - 是通过客户端或服务器中的调用确定的身份？
标识嵌入在AD响应中包含的access_token中。此令牌中包含nameid，您的应用可以与用户和角色相关联。 nameid类似于您的应用用于识别用户的电子邮件地址，用户名或其他唯一ID。
如何根据用户角色限制对API某些端点的访问？
你选择。当您的应用收到具有特定access_token的请求时，该令牌将通过其nameid与特定用户相关联，您可以为该用户分配任何角色和权限。基本上，将角色与nameid关联。
通过构建可用的现有中间件和库，我该怎么做才能实现这一目标？
There is an unfinished demo here，虽然它不使用Active Directory作为提供程序，但它使用内部提供程序。对于演示，用户名为shaun，密码为Testing123!。 The source code is here。
以下是the link to the source of another demo，但它不再使用Active Directory作为提供程序，而是使用Twitter。
关于OAuth和OpenID Connect的好处是我们可以使用我们想要的任何身份提供程序，因此您可以调整演示以使用Active Directory。
答案 1 :(得分：3)
除问题＃1（身份在服务方面得到验证）之外，您的所有问题都是非常开放的，需要超长的答案。 我建议阅读https://azure.microsoft.com/en-us/documentation/articles/active-directory-authentication-scenarios/ - 这是对许多现代认证中心的流程的一个很好的介绍，包括您正在关注的Web API。 阅读完毕后，您会在https://azure.microsoft.com/en-us/documentation/articles/active-directory-code-samples/中找到一组完整的示例 - 特别是，我建议您学习网络API，然后通过授权，查找您列出的3个问题的指导。 HTH！