Oauth2系列5：客户端凭据模式_oauth2 客户端模式-优快云博客

本文链接：https://blog.youkuaiyun.com/weigeshikebi/article/details/125629388

本文深入探讨OAuth2的客户端凭据模式，适用于后端系统间无用户参与的通信。该模式用于获取访问令牌，减少敏感信息暴露风险。流程包括客户端通过POST请求携带凭据获取令牌。一个API接口即可实现此过程，通常使用HTTPS确保安全。返回的令牌数据结构可不包含刷新令牌，因客户端可随时重新请求。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

传送门

在前面几节，对oauth2有了一个初步概念。这里重点讨论下客户端凭据

猝不及防的热

这几天真的有点热，又是在顶楼，更是热上加热。又舍不得开空调，只得干熬着。就像之前很火的一首歌岁月时脑里唱着

热是让人猝不及防的东西

征不过朝夕

有念着往昔

热不会放过任何人

不由得记得刚毕业时，和同学合租在拱墅区南霸的农民房里，也是顶楼，没有空调，晚上热的受不了，就把床立起来，睡地上。还是热，大半夜上顶楼打地铺。

时间是让人猝不及防的东西

征不过朝夕

有念着往昔

时间不会放过任何人

年轻的时候真好！！！那时候虽什么都没有，但也没有现在的种种焦虑，身体好，体力好，做事有激情，更好的是有一个虽分隔千里，现在还在联系的朋友！

容我滥情了一把

什么是客户端凭据模式

在前面介绍过授权码模式，密码模式这2种模式，客户端凭据模式也是oauth2的4种标准协议之一

客户端凭证（client credentials）

最后一种方式是凭证式（client credentials），适用于没有前端的命令行应用，即在命令行下请求令牌。

应用场景

客户端凭据模式主要应用于后端系统之间需要直接通信，但是没有用户参与的场景。比如某些开放平台，允许注册应用获取一些平台公共资源，比如平台的介绍信息，注册应用本身的信息，这些理论上是不需要用户进行授权的，而且也跟用户没有归属关系，这个时候就可以使用此模式

客户端凭据模式的目的，最终还是获取授权的令牌：如果每次都是拿着凭据来通过调用 Web API 的方式，来访问资源信息等，在调用这么多 API 的情况下，无疑增加了敏感信息的攻击面。如果是使用了 token 来代替这些“满天飞”的敏感信息，不就能很大程度上保护敏感信息数据了吗？这样，客户端只需要使用一次凭据数据来换回一个 token，进而通过 token 来访问资源数据，以后就不会再使用凭据了。

客户端凭据模式流程

客户端凭据模式的流程其实跟密码模式相似，整个流程可以归纳为一种步骤：第三方系统通过凭据获取令牌。那么对于系统接口设计来说，是不是一个API接口就可以满足呢？

其实是可以的，比如可以如下定义接口：

URL：http://oauth.x.com/token

请求方式：POST

请求参数：

字段说明
grantType client_credentials，固定值，表示客户端凭据模式
clientId 客户端 ID（client ID）
clientSecret 客户端密钥（client secret）

返回参数：
{ 
"access_token":"ACCESS_TOKEN", 
"expires_in":7200, 
"refresh_token":"REFRESH_TOKEN",
"scope":"SCOPE"
}

这个接口一般是从后端发起POST请求
出于安全，一般需要设置成HTTPS协议
这里面还要讨论一下，对于返回的token数据结构，对于刷新令牌来说，不是必要的，因为本身就是API接口调用，客户端可以随时调用，且不需要用户参与，所以refresh_token不一定要生成返回

字段	说明
grantType	client_credentials，固定值，表示客户端凭据模式
clientId	客户端 ID（client ID）
clientSecret	客户端密钥（client secret）