-
如何选择OIDC协议模式
控制台的协议如何配置
XAuth 的创建应用提供了协议向导，但是如何选择，以及选择的原理是什么？本节将详细的介绍，如何根据你的需求，选择不同的协议模式和配置。
下表将应用程序类型与相应的协议模式进行了一对一的展示，简单的说根据你需要的 token 类型、客户端应用程序类型来决定选择哪一种协议模式。
按应用类型
应用类型 OAuth 2.0 flow 有服务端的应用 授权码模式 Authorization Code 单页面应用 Authorization Code + PKCE （推荐）， Implicit flow Native 应用 Authorization Code + PKCE Trusted 密码模式 Resource Owner Password 服务 客户端凭证模式 Client Credentials 应用是否需要 id token
所有的协议模式都可以签发 access token，然而他们不都支持 id token
协议模式 Grant Type access token id token Authorization Code ✅ ✅ Authorization Code with PKCE ✅ ✅ Implicit ✅ ✅ Resource Owner Password ✅ ✅ Client Credentials ✅ ❌ 按客户端类型
通过下图可以根据你的需求快速匹配到合适的协议模式：
应用是否是公共客户端
当最终用户可能查看和修改代码时，客户端应用程序被视为公共应用程序。这包括单页应用 (SPA，Single-Page App) 或任何移动 app 或 PC 应用程序。在这两种情况下，应用程序都无法对恶意用户保密。
应用是 SPA 还是 Native 类型的应用程序?
如果应用是运行于能够支持 PKCE 所需的 Web Crypto 的浏览器的 SPA 应用，那么可以使用 Authorization Code + PKCE 的认证模式；
如果应用要在无法支持 PKCE 所需的 Web Crypto 的浏览器中运行中，需要使用 Implicit 认证模式。由于在 Implicit 模式下，无法保证 client secret 的保密性，所以除非其它的认证模式都不可用时不推荐使用 Implicit 模式。
如果是 Native 应用，则推荐使用 Authorization Code + PKCE 的认证模式。
应用是否有终端用户
当应用程序运行于终端用户无法直接访问的服务器时，我们认为该应用是安全可信的，因此在这种情况下应用可以保存 secret 作为认证的凭证。
如果应用只进行机器与机器之间（machine-to-machine）的交互，则需要使用 client Credentials 的认证模式。
应用客户端是否可信且其它模式不可用
当你同时拥有客户端应用程序和它所请求访问的资源时，应用程序是可信的，所以应用程序可以用来保存终端用户的用户名和密码。因此，当其它的认证模式都不可用时，可以使用这种需要高度信任关系的的认证模式：密码模式（resource owner password flow）
不同类型的流程
授权码模式 Authorization Code flow
授权码模式（authorization code flow）指的是第三方应用先和向 authorize endpoint 申请一个授权码，然后再用该授权码向 token endpoint 请求 token。
这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，token 则是储存在服务端，而且所有与资源服务器的通信都在服务端之间完成。这样的前后端分离，可以避免 token 泄漏。
Authorization Code + PKCE
在 SPA 应用以及 PC 客户端程序、移动 APP 程序等公共客户端应用中，固定的 client secret 保存在客户端中极易泄漏无法保证安全性。因此通过 PKCE（Proof Key for Code Exchange）方式用随机的 code_challenge 和 code_verifier 取代固定的 client secret 加强授权码模式的安全性。
PKCE 是对常规授权码模式的扩展，除了各个步骤中的 PKCE 的元素，整体流程上与常规的授权码模式基本一致。
注：SPA 等基于浏览器的应用使用授权码+PKCE 模式时，不支持 refresh token。
在基于 PKCE 的授权码模式中，应用客户端需要生成一个随机的认证码（code verifier） ，并通过认证码生成挑战码（code challenge）。然后应用客户端按照授权码的流程向 authorize endpoint 请求授权码时将 code challenge 附加到请求中。
当使用授权码向 token endpoint 请求 token 时，需要将认证码附加到请求中。授权服务器使用约定好的哈希算法对认证码进行哈希计算，并比对计算结果是否与挑战码一致，如果一致则证明 authorize endpoint 和 token endpoint 接收到的两个请求来源同同一个应用客户端。
另外，建议整个通信过程使用 Https 协议，使恶意程序将无法窃取 code_challenge 和 code_verifier。
简易模式 Impicit flow
当客户端是公共应用程序时，由于安全问题在客户端中不能保存 client secret ，在这种情况下推荐使用简易模式（或称为隐藏模式，Implicit flow），允许客户端直接向授权服务器的 authorize endpoint 请求 token，省去了授权码的中间步骤。
注 1：由于公共应用程序不能保证所存储的数据的私密性，所以简易模式下不支持 refresh token
注 2：出于安全上的考虑，仅在浏览器不支持 Web Crypto 时建议使用简易模式；对运行于支持 Web Crypto 的浏览器中的 SPA 类型应用，强烈建议使用授权码+PKCE 模式。
密码模式 Resource Owner Password flow
当高度信任应用客户端时，可以采用密码模式（Resource Owner Password flow）。用户向客户端提供自己的用户名和密码，客户端使用用户名密码向 token endpoint 请求 token
密码模式适用于客户端应用程序和受保护资源都高度受控可信的情况。
密码模式下客户端直接向 token endpoint 发起请求，而不需要像授权码模式和简易模式那样进行重定向。
客户端凭证模式 Client Credentials
客户端凭证模式用于没有最终端用户的服务器端应用程序，该模式通常是用于机器到机器的通信。 由于在客户端凭证模式下使用的是固定的 client secret 进行认证，所以该模式下应用必须是服务端的（也就是没有前端的应用），由应用使用 client secret 直接向 token endpoint 请求 access token 。
