Azure 企业实名 微软云 Azure 账号身份认证集成
别再让 Azure 登录变成‘薛定谔的授权’：一份人话版身份认证集成指南
你是不是也经历过——前端调了三天登录按钮，后端死活收不到 ID Token；运维同事深夜甩来一条报错：AADSTS50011: The reply url specified in the request does not match the reply urls configured for the application，而你盯着 Azure 门户里那堆「重定向 URI」「平台配置」「隐式授予」发呆，仿佛在读《天书·Azure 版》？别慌，今天咱们不讲 RFC 文档，不背协议名词，就用咖啡续命+真实踩坑经验，把 Azure 账号身份认证集成，掰开揉碎，喂到你嘴边。
第一步：先搞清你到底在跟谁打交道？Azure AD ≠ Windows AD
很多团队一上来就猛冲「Azure Active Directory」，结果发现——咦？我公司没部署域控制器，怎么连 AD 都没见着？醒醒，Azure AD 是云原生的身份服务，不是本地 AD 的搬砖工。它不管理你的文件服务器权限，也不跑在你机房的 DC 上。它是微软给你预装好的「云上身份证局」：管用户、管组、管应用访问策略，还顺手帮你对接 Office 365、Teams、甚至你自己的 SaaS 系统。记住一句话：Azure AD 是身份提供者（IdP），不是目录同步工具。想把本地 AD 用户拉上云？那是 Azure AD Connect 干的活，和本文认证集成无关——先划清楚楚的楚河汉界，后面才不会乱套。
第二步：OAuth2.0 是快递员，OpenID Connect 是快递单上的签名栏
微软文档里满屏飘着 OAuth2.0 和 OIDC，听着像玄学双修。其实极简理解：OAuth2.0 负责「授权」——比如你允许微信读取你的头像；OIDC 是在 OAuth2.0 基础上加了个 id_token，专干「认证」的事——证明「你就是你」。Azure 默认走的是 OIDC 流程，所以你最终要拿的不是 access_token（虽然它也有用），而是那个带用户基本信息（sub、email、name）的 JWT 格式 id_token。别傻乎乎只验 access_token 的过期时间，用户登录态靠的是 id_token 的 signature 和 nonce 校验——这一步漏了，等于把门锁换成纸糊的。
第三步：应用注册不是填表，是给 Azure AD 写一份「行为说明书」
进 Azure 门户 → Azure AD → 应用注册 → 新建。别急着点创建！关键字段全是雷区：
- 名称：随便写，但建议带环境前缀，比如「MyApp-Prod」，方便后期审计；
- 支持的账户类型：选「仅此组织目录中的帐户」还是「任何组织目录中的帐户」？前者是单租户，后者才是多租户——但多租户≠自动放行，你还得在代码里显式指定
organizations或common作为 authority，否则用户点登录直接 401； - 重定向 URI：这是最痛的痛点！
http://localhost:3000/auth/callback和https://myapp.com/auth/callback必须一字不差填进控制台，且协议、端口、路径全部严格匹配。HTTPS 不允许填 HTTP，/callback/和/callback视为不同地址，连尾部斜杠都不能错。曾经有兄弟因为开发环境用了http://127.0.0.1:3000，生产填了https://app.com，结果测试时一切正常，上线后全员 500——Azure 说：你没告诉我你能收这个快递，我不发。
填完别忘点「证书和密码」页，生成 client secret（或配证书），并记牢——页面刷新后就再也看不到了。另外，「API 权限」页必须手动勾选「Microsoft Graph」→「User.Read」，否则即使登录成功，调 Graph API 拿用户资料也会被拒。这不是可选项，是强制项。
第四步：RBAC 是管资源的，App Roles 才是管用户的
很多人以为在 Azure AD 里给用户分配「读者」「贡献者」角色就能控制应用内权限——错！RBAC（基于角色的访问控制）管的是 Azure 资源（VM、Storage、SQL），不是你写的 Web App。真要区分「管理员」「编辑员」「访客」，得用 App Roles：在应用注册的「清单」页，手动编辑 JSON，加入：
{
"appRoles": [
{
"allowedMemberTypes": ["User"],
"description": "Can manage content",
"displayName": "ContentAdmin",
"id": "a1b2c3d4-...",
"isEnabled": true,
"value": "ContentAdmin"
}
]
}然后去企业应用页，找到你的应用 → 用户和组 → 添加用户 → 分配角色。此时用户登录后，id_token 里会多一个 roles 数组，你的后端一读即知权限。比硬编码 if-else 判断邮箱域名靠谱一万倍。
第五步：那些让你凌晨三点改 DNS 的报错，其实都有套路
AADSTS50011：重定向 URI 不匹配。查三遍：代码里 redirect_uri 参数值、Azure 控制台填的值、浏览器地址栏实际跳转的值，三方必须一致。
AADSTS700016：应用未在租户中找到。多租户场景下，用户首次登录时需管理员同意（Consent）。别让用户自己点「同意」，要在登录 URL 里加 &prompt=admin_consent，并由全局管理员访问一次完成授权。
AADSTS50076：MFA 强制触发。不是错误，是安全策略生效。前端别崩，优雅提示「请完成双重验证」即可。
Token validation failed: 'nonce' claim is missing：OIDC 标准要求，请求时带 nonce，返回时必须校验。漏了？补上。用 msal.js 的话，它自动处理；手撸请求？记得生成随机 nonce 存 session，并在 token 解析后比对。
第六步：最后送你三条保命口诀
- 永远用 MSAL.js（v2+）或 Microsoft.Identity.Web，别手写 OAuth 流程——微软自己都承认手写容易翻车，这些 SDK 内置 PKCE、自动刷新、缓存管理，省下的 debug 时间够你喝十杯冰美式；
- 所有敏感配置（client_id、authority、redirect_uri）绝不硬编码，走环境变量或密钥 vault——曾经有项目把 dev 环境的 client_secret 提交到 GitHub，当天就被扫库机器人薅走，整个租户差点被当肉鸡；
- Azure 企业实名 日志！日志！日志！——在 token 获取前后打日志，记录 raw response、error code、timestamp。别等用户投诉才查，留痕才是排查之本。
写到这儿，你可能已经合上笔记本，准备去 Azure 控制台改配置了。提醒一句：改完别忘了「保存」——是的，Azure 有些页面点了「添加」按钮，还得手动点右上角「保存」才能生效。这反人类设计，我们栽过太多次。祝你集成顺利，登录丝滑，半夜不用爬起来修 auth。毕竟，工程师的尊严，不该耗在 401 和 500 之间来回横跳。
