Azure Active Directory应用注册如何建立信任关系？

注册应用会在你的应用与Microsoft身份平台之间建立信任关系。此信任是单向的：你的应用信任Microsoft身份平台，反之则不成立。

核心疑问 #

• 此处的“信任”具体指什么？应用注册又是如何建立该信任关系的？
• 注册本质是让应用被Azure AD知晓，但这如何让应用信任用于交互式登录跳转的AD？恶意AD能否冒充知晓任何使用其登录的应用？是否需要共享密钥来确保AD的真实性？HTTPS是否已建立该信任？
• 为何文档说信任是单向的（应用信任AD），而非AD验证应用（比如通过重定向URI拦截非法请求）？

原理拆解 #

1. 这里的“信任”到底是什么

这里的单向信任核心是应用信任Microsoft身份平台颁发的令牌的合法性：

• 应用在登录流程中会接收AD返回的ID令牌/访问令牌，应用会验证令牌的签名、签发者（issuer）、有效期等字段，验证依据是AD公开的公钥。
• 应用提前知晓并信任AD的合法签发者身份、令牌格式，所以才会接受并使用这些令牌确认用户身份。

2. 应用注册如何建立这个信任

应用注册的核心是让AD和应用达成双向的“身份共识”，文档强调的“单向信任”是从信任方向而非信息同步角度：

• 注册时，你会为应用配置唯一的客户端ID，以及允许的重定向URI、令牌类型等参数，这些信息存入Azure AD，让AD能识别该应用的合法请求。
• 同时，注册流程会让你获取应用凭据（客户端密钥或证书），以及知晓AD的合法元数据端点、令牌签发者地址——这些是应用验证AD令牌的关键依据，相当于应用“记住了合法AD的身份特征”，从而建立对AD的信任。

3. 关于恶意AD冒充的问题

恶意AD无法轻易冒充，核心靠两层保障：

• HTTPS传输安全：交互式登录跳转的目标是AD官方HTTPS端点，浏览器会验证AD服务器的SSL证书，确保通信对象是真实的Microsoft服务器，而非恶意仿冒站点。
• 令牌签名验证：即使恶意站点返回伪造令牌，应用验证签名时会使用AD公开的公钥（从合法元数据端点获取），伪造签名会无法通过验证，应用会拒绝该令牌。
• 不需要额外共享密钥验证AD真实性，AD的公钥公开可获取，应用通过信任该公钥对应的签发者，确认令牌合法。

4. 关于“反向验证”的误解

你提到的AD验证重定向URI，属于AD对应用请求合法性的校验，这是AD端的安全机制，但和文档所说的“单向信任”不是同一维度：

• 文档的“单向信任”指应用信任AD能合法签发令牌，而AD并不“信任”应用——AD只是根据注册信息验证应用请求是否合法（比如重定向URI是否匹配），但不会依赖应用的身份凭证确认应用合法性（除非是客户端凭据流这类特定场景）。
• 简单说：应用相信AD给的令牌是真的；AD只是核对应用请求是否符合预先注册的规则，但不会主动“信任”应用的身份。

内容的提问来源于stack exchange，提问作者Good Night Nerd Pride