使用 Oauth2/OpenID 连接构建 Web-API
Building a Web-API with Oauth2/OpenID connect
我试图从概念上和实践上理解如何利用 Azure AD 在我的 web-api 应用程序中执行带有 openID-connect 流的 oauth2。
重要的是，当向 API 发出请求时，我想知道 是谁 发出了请求。
我目前的理解是：-
- 我的客户端会检测到用户未登录并重定向到登录。
- 用户将提供他们的凭据，并连同 oauth2 令牌一起被重定向回客户端。
- 此令牌将提供给任何请求的 web-api 端点。
这就是让我感到困惑的地方。
我究竟如何使用此令牌来授权对特定资源的访问，确定谁在访问该资源，以及这样做的机制是什么？
我假设我需要重用令牌来调用 Azure AD 用户端点 - 如果令牌确实有效，AD 端点将 return 用户详细信息 -从而提供一些方法来确定令牌是否有效并提供有关用户身份的详细信息。可以通过 Azure AD 中的组成员身份来授权对资源的访问。
但是...
我只能假设这是一个已解决的问题，并且注意到按照这个例子使用了 OWIN 中间件
https://github.com/AzureADSamples/WebApp-WebAPI-OpenIDConnect-DotNet
但我仍然不确定到底发生了什么。
该服务提到了范围和声明，但我不明白它们的来源（我假设来自客户提供的令牌，但不确定）。服务必须在调用中接收身份信息。
为了安全起见，这让我想到了两点 -
在调用服务时提供的令牌需要在传输中得到保护（因此使用 HTTPS）- 以防止 MITM。
令牌需要以某种方式进行签名——我猜是通过使用客户端密码或其他方式——以防止令牌中的信息被欺骗。
谁能帮我收拾一下这个乱七八糟的烂摊子？
特别是-
如何确定API调用者的身份 - 身份是由客户端还是服务器中的调用确定的？
如何根据用户角色限制对 API 的某些端点的访问？
我该怎么做才能通过构建可用的现有中间件和库来实际实现这一目标？
免责声明：这不会是一个全面的答案。这是我的头顶。
OpenID Connect 在 OAuth 之上提供身份层。在您的情况下，Active Directory 提供 身份验证并发回 access_token。访问令牌 表示 AD 已验证的用户 。如果您使用 OpenID Connect，那么 AD 还会发送一个 id_token，其中可能包含其他身份信息（例如生日、头像以及 AD 公开的任何其他信息。）
OpenID Connect 和 Active Directory 都与您的应用分配给用户的角色没有任何关系；角色完全是您应用程序的管辖范围。您可以像往常一样分配用户角色；您将它们分配给 nameid 而不是电子邮件地址或用户名。您的应用不再需要对用户进行身份验证，但它确实需要为 nameid.
分配角色
How is the identity of the API caller determined - is identity determined from a call in the client or the server?
身份嵌入在 AD 包含在其响应中的 access_token 中。此令牌中将包含一个 nameid，您的应用可以将其与用户和角色相关联。 nameid 类似于电子邮件地址、用户名或您的应用用来识别用户的其他唯一 ID。
How to limit access to some endpoints of the API based on a user role?
你选择。当您的应用收到带有特定 access_token 的请求时，该令牌将通过其 nameid 与特定用户关联，您可以为该用户分配任何角色和权限。基本上，将角色与 nameid.
相关联
What do I do to practically achieve this by building on existing middleware and libraries available to me?
There is an unfinished demo here, though it doesn't use Active Directory as the provider, instead, it uses an internal provider. For the demo, the username is shaun and password is Testing123!. The source code is here。
这里是 the link to the source of another demo，但同样，它不使用 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/ 中找到一组完整的示例 - 特别是，我建议您研究网络 API 并通过授权找到您列出的 3 个问题的指导。 HTH！
我试图从概念上和实践上理解如何利用 Azure AD 在我的 web-api 应用程序中执行带有 openID-connect 流的 oauth2。
重要的是，当向 API 发出请求时，我想知道 是谁 发出了请求。
我目前的理解是：-
- 我的客户端会检测到用户未登录并重定向到登录。
- 用户将提供他们的凭据，并连同 oauth2 令牌一起被重定向回客户端。
- 此令牌将提供给任何请求的 web-api 端点。
这就是让我感到困惑的地方。
我究竟如何使用此令牌来授权对特定资源的访问，确定谁在访问该资源，以及这样做的机制是什么？
我假设我需要重用令牌来调用 Azure AD 用户端点 - 如果令牌确实有效，AD 端点将 return 用户详细信息 -从而提供一些方法来确定令牌是否有效并提供有关用户身份的详细信息。可以通过 Azure AD 中的组成员身份来授权对资源的访问。
但是...
我只能假设这是一个已解决的问题，并且注意到按照这个例子使用了 OWIN 中间件
https://github.com/AzureADSamples/WebApp-WebAPI-OpenIDConnect-DotNet
但我仍然不确定到底发生了什么。
该服务提到了范围和声明，但我不明白它们的来源（我假设来自客户提供的令牌，但不确定）。服务必须在调用中接收身份信息。
为了安全起见，这让我想到了两点 -
在调用服务时提供的令牌需要在传输中得到保护（因此使用 HTTPS）- 以防止 MITM。
令牌需要以某种方式进行签名——我猜是通过使用客户端密码或其他方式——以防止令牌中的信息被欺骗。
谁能帮我收拾一下这个乱七八糟的烂摊子？
特别是-
如何确定API调用者的身份 - 身份是由客户端还是服务器中的调用确定的？
如何根据用户角色限制对 API 的某些端点的访问？
我该怎么做才能通过构建可用的现有中间件和库来实际实现这一目标？
免责声明：这不会是一个全面的答案。这是我的头顶。
OpenID Connect 在 OAuth 之上提供身份层。在您的情况下，Active Directory 提供 身份验证并发回 access_token。访问令牌 表示 AD 已验证的用户 。如果您使用 OpenID Connect，那么 AD 还会发送一个 id_token，其中可能包含其他身份信息（例如生日、头像以及 AD 公开的任何其他信息。）
OpenID Connect 和 Active Directory 都与您的应用分配给用户的角色没有任何关系；角色完全是您应用程序的管辖范围。您可以像往常一样分配用户角色；您将它们分配给 nameid 而不是电子邮件地址或用户名。您的应用不再需要对用户进行身份验证，但它确实需要为 nameid.
How is the identity of the API caller determined - is identity determined from a call in the client or the server?
身份嵌入在 AD 包含在其响应中的 access_token 中。此令牌中将包含一个 nameid，您的应用可以将其与用户和角色相关联。 nameid 类似于电子邮件地址、用户名或您的应用用来识别用户的其他唯一 ID。
How to limit access to some endpoints of the API based on a user role?
你选择。当您的应用收到带有特定 access_token 的请求时，该令牌将通过其 nameid 与特定用户关联，您可以为该用户分配任何角色和权限。基本上，将角色与 nameid.
What do I do to practically achieve this by building on existing middleware and libraries available to me?
There is an unfinished demo here, though it doesn't use Active Directory as the provider, instead, it uses an internal provider. For the demo, the username is shaun and password is Testing123!. The source code is here。
这里是 the link to the source of another demo，但同样，它不使用 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/ 中找到一组完整的示例 - 特别是，我建议您研究网络 API 并通过授权找到您列出的 3 个问题的指导。 HTH！