重要的是,当向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 Connect,那么AD也会发送一个id_token,其中可能包含其他身份信息(例如生日,头像以及AD公开的其他内容).
OpenID Connect和Active Directory都与您的应用分配给用户的角色无关;角色完全是你的应用程序的bailiwick.您可以像平常一样分配用户角色;您将它们分配给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,虽然它不使用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.
