我试图从概念上和实践上理解如何在我的web-api应用程序中使用openID-connect流执行oauth2，利用Azure AD。
重要的是，当向API发出请求时，我想知道是谁发出请求的。我目前的理解是:-
- 我的客户端将检测到用户没有登录，并重定向到登录。
- 用户将提供他们的凭证，并被重定向回客户端，以及oauth2令牌。
- 此令牌将提供给web-api端点的任何请求。
这对我来说是模糊的。
我究竟如何使用这个令牌来授权对特定资源的访问，确定谁在访问该资源，以及这样做的机制是什么?
我假设我需要重用令牌来调用Azure AD用户端点-如果令牌确实有效，AD端点将返回用户详细信息-从而提供一些确定令牌有效的方法，并提供有关用户身份的详细信息。对资源的授权访问可以通过Azure AD中的组成员身份来完成。
但是…
我只能假设这个问题已经解决了，并且已经注意到按照这个例子使用了OWIN中间件
https://github.com/AzureADSamples/WebApp-WebAPI-OpenIDConnect-DotNet但是我仍然不确定到底发生了什么。
服务提到了作用域和声明，但我不明白这些是从哪里派生出来的(我假设是从客户端提供的令牌派生出来的，但不确定)。服务必须在呼叫中接收到身份信息。
这给我带来了两点，为了安全-
在调用服务时提供的令牌需要在传输中得到保护(因此使用HTTPS) -以防止MITM。
令牌需要以某种方式签名-我猜是通过使用客户端秘密或其他方式-以防止令牌中的信息被欺骗。
特别是-
API调用者的身份是如何确定的-身份是由客户端还是服务器端的调用确定的?
如何根据用户角色限制对API的某些端点的访问?
我怎么做才能通过构建现有的中间件和库来实现这一目标?
免责声明:这不是一个全面的答案。我一时想不起来。
OpenID Connect在OAuth之上提供了一个身份层。在您的示例中，Active Directory 提供身份验证并返回access_token。访问令牌表示AD已经认证的用户。如果你做OpenID连接，那么AD也会发送一个id_token，其中可能包含额外的身份信息(如生日，头像，以及AD暴露的任何其他信息)
OpenID Connect和Active Directory都与你的应用分配给用户的角色没有任何关系;角色完全属于你的应用。你可以像平常一样分配用户角色;您可以将它们分配给nameid，而不是电子邮件地址或用户名。您的应用程序不再需要验证用户，但它确实需要为nameid分配角色。
如何确定API调用者的身份-身份是由客户端还是服务器中的调用确定的?
标识嵌入在AD在其响应中包含的access_token中。这个令牌将有一个nameid，你的应用程序可以与用户和角色关联。nameid就像一个电子邮件地址、用户名或其他唯一的id，你的应用程序使用它来识别用户。
你选择如何根据用户角色限制对API的某些端点的访问?
。当您的应用程序接收到具有特定access_token的请求时，该令牌将通过其nameid与特定用户相关联，并且您可以为该用户分配任何角色和权限。基本上，将角色与nameid关联。
我该怎么做才能在现有的中间件和库的基础上实现这个目标?
这里有一个未完成的演示，尽管它没有使用Active Directory作为提供程序，而是使用内部提供程序。在demo中，用户名为"shaun"，密码为"Testing123!"。源代码在这里。
这是另一个演示的源代码链接，尽管它没有使用Active Directory作为提供者，而是使用Twitter。
关于OAuth和OpenID Connect的好处是我们可以使用任何我们想要的身份提供者，所以你可以调整演示来使用Active Directory。
除了问题#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/上找到一套完整的示例——特别是，我建议你研究一下web API，并通过授权来找到你列出的3个问题的指导。HTH !