1、授权码许可与统一门户集成
在很多软件系统集成项目中，系统集成商会将各个软件厂商/部门的系统集成到一个门户中，所有系统提供统一入口，供用户统一访问。作为一个系统，用户肯定不希望进入每个系统都要重新登录一次，需要打通各系统的用户身份认证与单点登录。也就是用户登录到主门户后，可以不用再次输入用户名密码就可以使用相同的账号访问到其他子系统。
同样的，各系统也不希望各自维护一份用户认证数据，于是抽象一个用户管理与认证中心（IAM，Identity and Access Management）成为了经典设计。IAM 统一管理用户、角色、权限等信息，并提供用户服务、认证服务、授权服务等能力。
所有业务系统涉及系统接入、访问控制、认证授权、用户信息获取等全部经过 IAM。这样，用户得到集中管理，并与业务解耦。用户授权的需要成为了系统公共服务，十分契合 OAuth 2 的应用场景。
下面就按照授权码许可分析下集成过程。
2、角色分配
除了客户端，其余几种角色都很好划分。
能够访问系统的用户就是资源拥有者，系统的资源是面向用户准备的。
IAM 是聚合类多种角色的统一实体，OAuth 2 里的受保护资源与授权服务都由 IAM 提供。也就是客户端管理、用户身份认证、用户访问权限控制、用户信息开放等。提供的授权服务用于主系统接入更多子系统，提供的用户信息就是受保护资源，并且对申请获取用户信息的访问提供校验能力。
至于客户端，我是这么认为的。主系统与子系统整体来看是一个客户端，各自也都是客户端，因为都有申请授权获取受保护资源的需要。只不过，拥有统一门户的主系统是客户端代理，它负责管理客户端和向授权端点发起授权申请；集成到统一门户的众多子系统也是客户端，负责提供授权码接收端点与重定向 URI。
职责细化一下，主系统负责管理子系统，保证授权申请的唯一性，不允许子系统发起申请，约束重定向 URI 安全可控，并管理子系统的权限范围。子系统负责处理授权申请的后续过程，管理与使用令牌，获取所需资源。
- 用户：资源拥有者，浏览器代理用户
- 主系统：客户端代理，提供统一门户用于集成子系统门户
- 子系统：客户端，集成门户到统一门户中，处理与 IAM 的授权流程并获取资源
- IAM：集成授权服务与受保护资源服务等，提供授权服务、用户认证、账户管理、用户访问管理、开放能力（需要经过用户认证中心验证）等
3、门户集成流程
sequenceDiagram
主系统 -->> IAM: 1、注册客户端，分配到主系统的clientId
子系统 -->> IAM: 1、携带子系统重定向URI，注册客户端，分配到子系统的clientId
子系统 -->> 主系统: 1、携带子系统重定向URI、clientId，注册客户端
用户 ->> 主系统: 2、账号密码、二维码等方式登录，进入统一门户
用户 ->> 主系统: 2、准备访问子系统
主系统 ->> IAM: 2、前端信道携带子系统重定向URI，访问授权端点
IAM -->> 子系统: 2、前端信道重定向回子系统，返回code
子系统 ->> IAM: 2、后端信道携带code访问令牌端点
IAM ->> 子系统: 2、颁发令牌
子系统 ->> 子系统: 3、解析令牌等获取用户信息（可用令牌换取IAM资源）
子系统 -->> 用户: 3、重定向返回子系统门户页面
于是，整体集成流程如下：
1、主系统和子系统分别向 IAM 注册客户端，子系统再向主系统注册客户端
2、用户访问子系统首先需要在主系统保持登录状态，主系统向 IAM 发起授权申请，子系统接收授权码后处理后续授权流程，IAM 经过验证后颁发令牌
3、子系统拿到令牌后从 IAM 获取用户信息等受保护资源，对用户来说主系统与子系统使用了相同的用户信息，门户集成完成，单点登录打通
