Azure AD（二）调用受Microsoft 标识平台保护的 ASP.NET Core Web API 下

一，引言

　　上一节讲到如何在我们的项目中集成Azure AD 保护我们的API资源，以及在项目中集成Swagger，并且如何把Swagger作为一个客户端进行认证和授权去访问我们的WebApi资源的？本节就接着讲如何在我们的项目中集成 Azure AD 保护我们的API资源，使用其他几种授权模式进行授权认证，好了，开始今天的表演。

二，正文

1，access_token的剖析！

　　上一篇结尾我们成功的拿到了 access_token，并且通过 access_token 验证获取到调用Api资源的结果。我们先从swagger中去复制access_token，如图所示：

然后去 JWT.IO 解析 token

以下是解析出的全部内容，牵扯到个人隐私的内容，以使用 ‘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等等信息

着重看以下这几个参数：

　　1，aud（audience）：听众。这里直译起来比较拗口，其实说白了，就是这个令牌用于谁，使用令牌去访问谁，谁就是audience。

　　2，iss（Issuer）：颁发者。是只谁颁发的这个令牌，很显眼就我们azure认证的一个域在加上我们创建的这个租户

　　3，iat：令牌颁发时间

　　4，exp：令牌过期时间，与上面的颁发时间相差5分钟

　　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的这套认证授权也是很好入手的。

2，使用 Resource Owner Password Credentials 访问 API 资源

　　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可能存了用户密码，此模式仅用于受信任的客户端。复制会发生密码泄露。所以不推荐使用。

当然，我们也会根据实际项目的情况选择不同的授权模式。

3，使用 Client Credentials 访问资源

　　客户端凭证模式，是最简单的授权模式，因为授权的流程仅发生在客户端和授权认证中心之间。适用场景为服务器与服务器之间的通信。

　　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/yunqian44/Azure.AD.WebApi.git

作者：Allen

版权：转载请在文章明显位置注明作者及出处。如发现错误，欢迎批评指正。