OIDC（OpenID Connect）是一个基于OAuth 2.0协议的身份认证标准协议。
名词说明
OpenID Provider（OP）: OIDC 授权服务器，负责签发 ID Token。
Relying Party（RP）：请求方的应用。
End-User（EU）：用户，ID Token 的信息中会包含终用户的信息。
ID Token：JWT 格式的授权 Claims。Claims 中包含用户信息字段（例如名称或电子邮件地址）和其他元数据。
UserInfo Endpoint：用户信息接口，通过 ID Token 访问时返回用户信息。
运行流程
1. 请求方应用发送认证请求到 OIDC 授权服务器。
2. OIDC 授权服务器对用户进行认证与授权。
3. OIDC 授权服务器返回认证信息，包含 ID Token、Access Token和Refresh Token。
4. 请求方应用携带 Access Token 发送请求到 UserInfo Endpoint。
5. UserInfo Endpoint 返回 End-User 的 Claims。
OIDC 功能
实现 OIDC 场景模式
创建 OIDC 应用时指定的 grantType，只针对从数字身份管控平台（员工版）门户发起登录的场景，grantType 设置默认支持 authorization_code ，授权成功后返回 code；OIDC 应用不支持简化模式（ implicit）。
对于从应用系统发起登录的四种基础模式，除简化模式以外均支持，应用发起登录重定向或接口调用时，根据实际情况传入各模式对应的 response_type 参数或 grant_type 参数即可。
支持令牌刷新
提供令牌刷新接口，应用使用 refresh_token 换取新的 access_token、id_token。
支持 PKCE 模式
授权码模式下，支持 PKCE 校验码验证。PKCE 模式适用于功能逻辑主要在客户端完成的 Native App。因为 Native App 没有浏览器那样的 cookie 支持，CP 服务器没有 session 这样的东西来保存 state 参数从而防止 CSRF，所以使用 PKCE 的 code_verifier 和 code_challenge 来防止 CSRF。
步骤如下：
这里主要考虑到的是，Native App 必须经过浏览器才能进行 redirect 操作，在下图的第③步中，由于使用了 App 的 custom schemer，如果有恶意 App 注册了同一个 schemer，则不能保证第③步的重定向会回到您的 App。
