做者:Allen
版权:转载请在文章明显位置注明做者及出处。如发现错误,欢迎批评指正。
上一节讲到如何在咱们的项目中集成Azure AD 保护咱们的API资源,以及在项目中集成Swagger,而且如何把Swagger做为一个客户端进行认证和受权去访问咱们的WebApi资源的?本节就接着讲如何在咱们的项目中集成 Azure AD 保护咱们的API资源,使用其余几种受权模式进行受权认证,好了,开始今天的表演。🎉🎉🎉🎉🎉git
上一篇结尾咱们成功的拿到了 access_token,而且经过 access_token 验证获取到调用Api资源的结果。咱们先从swagger中去复制access_token,如图所示:github
而后去 JWT.IO 解析 tokenapi
如下是解析出的所有内容,牵扯到我的隐私的内容,以使用 ‘x’ 符号代替,还请见谅服务器
{ "aud": "f38ec09d-203e-4b2d-a1c1-faf76a608528", "iss": "https://sts.chinacloudapi.cn/53359126-8bcf-455d-a934-5fe72d349207/", "iat": 1589374088, "nbf": 1589374088, "exp": 1589377988, "acr": "1", "aio": "AUQAu/8HAAAABTQ0iHchtR+GpkOehfH2AYXoIa0tBYg0sf1atq88824rp/+ucL2LpSdCZB8SvLbZ7dpzxUh/BUThEiz5r05COg==", "amr": [ "pwd" ], "appid": "62ca9f31-585c-4d28-84b6-25fb7855aed0", "appidacr": "0", "email": "xxx@xxx.partner.onmschina.cn", "family_name": "xxx", "given_name": "xxx@xxx.partner.onmschina.cn", "idp": "https://sts.chinacloudapi.cn/71c1d8b2-6eec-4ae9-8671-208667b351c9/", "ipaddr": "113.201.51.xxx", "name": "xxx@xxx.partner.onmschina.cn yun", "oid": "0f7b8378-d133-4d76-8e5c-daf93a553b6e", "scp": "Order.Read", "sub": "-FvDwjpV6m3ZHBCC-MePlP-iSqmHi39_s5wvTCagThU", "tid": "53359126-8bcf-455d-a934-5fe72d349207", "unique_name": "xxx@xxx8.partner.onmschina.cn", "uti": "V1-3tIF2nEWUH7CH1FkOAA", "ver": "1.0" }
从这些信息不难看到,令牌的颁发者,颁发时间,失效时间,客户端Id等等信息app
着重看如下这几个参数:post
1,aud(audience):听众。这里直译起来比较拗口,其实说白了,就是这个令牌用于谁,使用令牌去访问谁,谁就是audience。学习
2,iss(Issuer):颁发者。是只谁颁发的这个令牌,很显眼就咱们azure认证的一个域在加上咱们建立的这个租户测试
3,iat:令牌颁发时间spa
4,exp:令牌过时时间,与上面的颁发时间相差5分钟3d
5,appid:客户端Id,就是在Azure AD里面给Swagger注册的客户端应用的Id
6,scp:权限范围,咱们为Swagger受权访问WebApi的权限
看到这里,是否是感受和 Identity Server 4受权验证中心的好多配置特别类似。是的,这里也不要感受到奇怪,Azure AD 也是基于OAuth 2.0和Open Id Connect协议的一种认证受权体系。只要有了 Identity Server 4的一些基础,学习Azure AD的这套认证受权也是很好入手的。
Resource Owner其实就是User,密码模式相较于客户端凭证模式,多了一个参与者,就是User。经过User的用户名和密码向认证中心申请访问令牌。
按照惯例,在postman中直接进行调用order的接口。
ResponseCode:401,提示没有权限。
1)为WebApi应用建立客户端密码
选择过时时间,点击 ”添加“
复制这个密码的值,提示如下,切换到其余页面后,就没法再进行复制了,全部提早先复制好。
2)查看资源全部者
选择 管理=》全部者 打开资源全部者页面
图上显示已经有一个全部者帐号,有人就问了,本身明明没有添加任何全部者信息,为何就凭空冒出来一个全部者帐号。其实不难看出,这个帐号就是咱们当前azure portal的登陆帐号,也是当前订阅的管理员帐号,并且咱们在建立MyCommany这个租户的时候也是使用的当前登陆的帐号,全部当前登陆的帐号也就天然而然的成为当前租户下应用注册的资源全部者。
3)查看WebApi的做用域
选择 管理=》公开 API
复制 WebApi的做用域
4)查看WebApi的终结点
复制当前应用程序的 OAuth 2.0令牌终结点(v2)连接,注意圈起来的 organization 参数,这个须要换成当前应用程序所在的租户的Id。
5)测试
1)统一验证,获取token
tenant:应用程序计划对其进行操做的目录租户。参数必传
client_id:分配给应用的应用程序ID,能够在注册应用的门户中找到。参数必传。
scope:在此请求中针对 scope参数传递的值应该是所需资源的资源标识符。参数可选。
client_secret:在应用注册门户中为应用生成的客户端机密。参数必传
grant_type:必须设置为 password。参数必传
username:用户的电子邮件地址
password:用户的密码
2)访问 api/order
砰,成功!此处应该有掌声🎉🎉🎉🎉🎉,成功的经过验证,而且获取到 api资源,可是这种模式是最不推荐的,由于client可能存了用户密码,此模式仅用于受信任的客户端。复制会发生密码泄露。因此不推荐使用。
固然,咱们也会根据实际项目的状况选择不一样的受权模式。👇
客户端凭证模式,是最简单的受权模式,由于受权的流程仅发生在客户端和受权认证中心之间。适用场景为服务器与服务器之间的通讯。
1)统一验证,获取token,须要额外注意此处的租户Id,以及scope
tenant:应用程序计划对其进行操做的目录租户。参数必传
client_id:分配给应用的应用程序ID,能够在注册应用的门户中找到。参数必传。
scope:在此请求中针对 scope参数传递的值应该是所需资源的资源标识符。参数必传。
client_secret:在应用注册门户中为应用生成的客户端机密。参数必传
grant_type:必须设置为 client_credentials。参数必传
这时候,就又有人问了,为何这里的 scope 参数的值和上面不同,确实,我也有这个疑问,后来找到微软官方给个人文档解释道:
在此请求中针对 scope
参数传递的值应该是所需资源的资源标识符(应用程序 ID URI),并附有 .default
后缀。 在 Microsoft Graph 示例中,该值为 https://graph.microsoft.com/.default
。
此值告知 Microsoft 标识平台终结点:在为应用配置的全部直接应用程序权限中,终结点应该为与要使用的资源关联的权限颁发令牌
使用共享机密访问令牌请求:https://docs.microsoft.com/zh-cn/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow
2)访问 api/order
砰,成功,再次撒花祝贺,🎉🎉🎉🎉🎉!这种模式直接是经过 client id 和 client secret 来获取 access_token,该方法一般用于服务器之间的通信
以上就是使用 资源持有者密码受权以及 客户端凭据受权两种受权模式。到此 关于ASP.NET Core Web Api 集成 Azure AD 的受权认证暂时告一段落。
今天的文章大概介绍了若是在咱们的项目中集成 Azure AD,以及如何使用 Resource Owner Password Credentials(资源持有者密码认证)和Client Credentials(客户端凭证)
下一篇继续介绍 Azure AD B2C 的相关内容。
github:https://github.com/allentmater/Azure.AD.WebApi.git
做者:Allen
版权:转载请在文章明显位置注明做者及出处。如发现错误,欢迎批评指正。