1.2.4 授信客户端模式
1.授权请求示例
授信客户端（Client Credentials Grant）模式的标准模式常用于第三方应用直接访问开放平台的场景，在这种场景下不需要用户进行授权，而是由第三方应用直接发起授权，并获取授权信息。
授信客户端模式在实际应用中有变种授信客户端模式，主要用于自研应用的授权，即自研应用通过传递自身的client_id和client_secret，获取在创建应用时被赋予的所有权限。
注意
一般用户在创建自研应用时会绑定自己的账号，所以获取的权限为绑定账号的权限。
步骤1 无论是标准授信客户端模式还是变种授信客户端模式，在进行授权时，发起的请求没有任何区别，会直接创建如示例1.9所示的授权请求。
示例1.9 授信客户端模式的授权请求
示例1.9中各参数的含义如下。
• client_id：第三方应用在开放平台注册完成后获取的唯一标识。
• client_secret：第三方应用在开放平台注册完成后获取的密码。
• grant_type：OAuth 2规定在标准授信客户端模式下，该字段的值为client_credentials；在变种授信客户端模式下，该字段的值为self_credentials。授权系统会根据该字段进行场景必要参数的校验，在验证通过后执行相关流程。
步骤2 授权系统收到请求后，根据grant_type进行后续流程。
• 如果grant_type为client_credentials，则进行标准的授信客户端模式的授权流程，即只返回access_token信息。标准授信客户端模式的授权信息如示例1.10所示。该模式返回的access_token信息，只能调用开放平台所开放给第三方应用的、与用户无关的能力。
示例1.10 标准授信客户端模式的授权信息
• 如果grant_type为self_credentials，则获取绑定的用户信息并生成授权信息，如示例1.6所示。
2.系统交互流程
下面通过图1-4来介绍变种授信客户端模式在grant_type为self_credentials时的授权流程。
图1-4 变种授信客户端模式的授权流程
在注册成自研应用时，为第三方应用绑定用户信息。
步骤1 第三方应用发起绑定用户信息请求。
步骤2 授权系统通过后台接口验证用户信息。
步骤3 认证系统校验成功后会返回用户的真实信息。
步骤4 在授权系统中绑定用户信息与应用信息。
步骤5 授权系统向第三方应用返回绑定成功的信息。
下面是第三方应用的授权流程。
步骤6 第三方应用向授权系统请求获取access_token信息，详见示例1.9。
步骤7 授权系统向第三方应用返回access_token信息，详见示例1.6。
标准授信客户端模式的授权流程比较简单，只需第三方应用直接发起如示例1.9所示的请求，此时grant_type为client_credentials，即可直接获取如示例1.10所示的授权信息。
总结
关于四种授权模式的应用场景。
• 隐式授权模式由于存在安全问题，在工作实践中应用较少。
• 授权码授权模式基于前后端通道分离的方式，提供了很强的安全性，因此成为应用最为广泛的授权模式。
• 授信客户端密码模式会直接暴露密码给第三方应用，在使用该模式时要求第三方应用有良好的安全措施，并且是完全值得信任的伙伴，如子公司。
• 在OAuth 2所定义的授信客户端模式（标准授信客户端模式）中，主要是开放平台将开放系统中与用户无关的功能开放给第三方应用。在变种授信客户端模式中，由于已经将开放系统的用户与第三方应用进行了绑定，因此在进行授权时，可以获取所绑定的用户数据和相关功能。这种变种授信客户端模式一般用于自研应用的授权场景。