本文主要目的为：指导开发者进行自有服务与Azure AD统一认证的集成，以及阐述云端用户数据同步的实现方案。本文除了会介绍必要的概念、原理、流程外，还会包含Azure门户设置说明，以及使用Fiddler进行全流程的实操验证，同时还会结合实际的业务需求提出具体的方案建议及关键实现方法的说明，以此达到开发指导的效果。
1. 基础概念
1.1 Azure AD
Azure Active Directory，简称 Azure AD，是微软提供的云身份验证服务，用于管理用户身份和访问权限。它是基于标准的开放式身份协议构建的，可以与多种应用程序和服务集成，包括云应用程序、本地应用程序和移动应用程序。
1.1.1 Azure AD 主要功能
- 身份验证和授权管理： Azure AD 提供了多种身份验证方式，包括用户名和密码、多重身份验证、SSO（单一登录）等，以确保用户身份的安全性。它还可以管理用户对资源的访问权限，并控制用户能够执行的操作。
- 集成式身份管理： Azure AD 可以与其他标识提供者集成，包括本地 Active Directory、LDAP、SAML 和 OAuth，使用户可以使用他们已有的帐户登录到 Azure AD 中的应用程序和服务。
- 应用程序集成： Azure AD 支持与各种应用程序和服务的集成，包括 Microsoft 365、Azure、SaaS 应用程序、自定义应用程序等。它提供了一种安全的方式来管理和控制用户对这些应用程序的访问权限。
- 安全和合规性： Azure AD 提供了安全性和合规性功能，包括多重身份验证、条件访问、安全策略、审计日志等，以帮助组织保护其数据和资源。
总之，Azure AD 是一个灵活且功能强大的身份验证和访问管理平台，可以帮助组织实现身份验证、授权和安全管理的统一化。从本质上来说，Azure AD 是基于 OAuth 2.0 和 OpenID Connect 规范的。OAuth 2.0 是一种用于授权的开放标准，用于安全地委托访问令牌，而 OpenID Connect 则是在 OAuth 2.0 的基础上添加了身份验证的协议。Azure AD 结合了这两种标准，以提供身份验证和授权功能，支持多种身份验证方法，并提供与其他服务和应用程序的集成。
需要补充说明的是Microsoft 将 Azure Active Directory (Azure AD) 更名为 Microsoft Entra ID，以介绍产品的多云多平台功能、缓解与 Windows Server Active Directory 的混淆，并统一 Microsoft Entra 产品系列。详见官方文档：https://learn.microsoft.com/zh-cn/entra/
1.1.2 Azure AD 与 ADFS区别
Azure AD 和 Active Directory Federation Services（ADFS）都是由微软提供的身份认证解决方案，但它们在一些方面有所不同：
- 部署位置
Azure 统一认证是基于云的身份认证解决方案，完全托管在 Microsoft Azure 云平台上。
ADFS 是一个本地部署的身份认证解决方案，通常部署在组织的本地网络中。 - 适用范围
Azure 统一认证是为云环境和混合云环境设计的，可以为云服务、SaaS 应用程序以及本地应用程序提供身份验证和访问控制。
ADFS 主要用于提供单点登录 (SSO) 和基于标准的身份验证服务，通常用于本地应用程序和企业资源的身份认证。 - 标准支持
Azure 统一认证支持 OAuth 2.0 和 OpenID Connect 等开放标准，使其能够与多种应用程序和服务集成。
ADFS 支持标准的身份验证协议，如SAML（Security Assertion Markup Language）和 WS-Federation（Web Services Federation）。 - 管理和维护
Azure 统一认证是一种完全托管的服务，由 Microsoft 管理和维护，无需组织自行管理基础设施。
ADFS 需要组织自行部署、配置和维护，需要更多的 IT 管理工作。 - 灵活性和扩展性
Azure 统一认证提供了更高的灵活性和扩展性，可以通过添加和配置不同的功能组件来满足不同的身份验证和授权需求。
ADFS 在本地部署方面更加灵活，可以根据组织的特定需求进行自定义和配置。
综上所述，Azure 统一认证适用于云环境和混合云环境，提供了更多的托管功能和集成选项，而 ADFS 则更适用于需要本地部署、自定义和控制的场景。关于ADFS及AD的部署配置可以参考：https://blog.csdn.net/camelials/article/details/134857159
1.2 微软Graph
Microsoft Graph 是微软提供的统一 API 平台，用于访问 Microsoft 365 中的各种数据和服务。它提供了一种统一的方式来访问多种 Microsoft 产品和服务的数据，包括 Office 365、Azure Active Directory、Exchange Online、SharePoint 等。
理解 Microsoft Graph 可以从以下几个方面来看：
- 统一访问数据和服务：Microsoft Graph 提供了一个统一的终结点，使开发者可以通过一组 API 来访问各种 Microsoft 产品和服务中的数据和功能，而不需要与每个服务单独交互。
- 多种数据类型支持：Microsoft Graph 支持访问多种类型的数据，包括用户信息、邮件、日历、文件、组织结构等。这些数据可以用于构建各种类型的应用程序和解决方案。
- RESTful API：Microsoft Graph 的 API 是基于 RESTful 架构的，使用标准的 HTTP 方法和 URL 结构进行访问。这使得它易于使用和集成到现有的应用程序和开发工具中。
- 权限控制和安全性：Microsoft Graph 提供了严格的权限控制机制，开发者需要通过 OAuth 2.0 认证来获取访问权限，并在访问数据时遵循权限范围的规定，确保数据的安全性和隐私保护。
- 实现业务逻辑：通过 Microsoft Graph，开发者可以实现各种业务逻辑，例如获取用户信息、发送邮件、管理文件、创建团队等。它可以帮助开发者构建智能化、协作化的应用程序和解决方案。
总的来说，Microsoft Graph 提供了一种统一、灵活的方式来访问 Microsoft 365 中的数据和服务，为开发者提供了丰富的功能和资源，帮助他们构建创新的应用程序和解决方案。Microsoft Graph 中的主要服务和功能可以参考官方文档：https://learn.microsoft.com/zh-cn/graph/overview-major-services
2. 统一认证流程及实操验证
微软Graph分为中国版（由上海世纪互联运营）和国际版，两者大致一样，但是也存在一些差异，例如：Portal门户设置UI不同，终结点不同，一些接口的参数和约定不同等，这里以全球版的v1.0进行介绍。
2.1 前置条件
2.1.1 应用程序注册/设置
1、基本设置
应用程序主要基本设置如上图，其中租户ID（tenant_id）、应用程序ID（client_id）、客户端凭据（client_secret）、重定向URL（redirect_uri）等在后续的授权及微软Graph API调用的时候需要使用。例如：
### 登录授权终结点
https://login.microsoftonline.com/#{
tenant}/oauth2/v2.0/authorize?client_id=#{
client_id}&response_type=code&redirect_uri=#{
redirect_uri}
### 授权码获取Token
POST https://login.microsoftonline.com/#{
tenant}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded
client_id=#{
client_id}
&scope=User.Read
&redirect_uri
最低0.47元/天 解锁文章
扫一扫
1532
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
