传送门
在前面几节,对oauth2有了一个初步概念。这里重点讨论下客户端凭据
猝不及防的热
这几天真的有点热,又是在顶楼,更是热上加热。又舍不得开空调,只得干熬着。就像之前很火的一首歌岁月时脑里唱着
热是让人猝不及防的东西
征不过朝夕
有念着往昔
热不会放过任何人
不由得记得刚毕业时,和同学合租在拱墅区南霸的农民房里,也是顶楼,没有空调,晚上热的受不了,就把床立起来,睡地上。还是热,大半夜上顶楼打地铺。
时间是让人猝不及防的东西
征不过朝夕
有念着往昔
时间不会放过任何人
年轻的时候真好!!!那时候虽什么都没有,但也没有现在的种种焦虑,身体好,体力好,做事有激情,更好的是有一个虽分隔千里,现在还在联系的朋友!
容我滥情了一把
什么是客户端凭据模式
在前面介绍过授权码模式,密码模式这2种模式,客户端凭据模式也是oauth2的4种标准协议之一
客户端凭证(client credentials)
最后一种方式是凭证式(client credentials),适用于没有前端的命令行应用,即在命令行下请求令牌。
应用场景
客户端凭据模式主要应用于后端系统之间需要直接通信,但是没有用户参与的场景。比如某些开放平台,允许注册应用获取一些平台公共资源,比如平台的介绍信息,注册应用本身的信息,这些理论上是不需要用户进行授权的,而且也跟用户没有归属关系,这个时候就可以使用此模式
客户端凭据模式的目的,最终还是获取授权的令牌:如果每次都是拿着凭据来通过调用 Web API 的方式,来访问资源信息等,在调用这么多 API 的情况下,无疑增加了敏感信息的攻击面。如果是使用了 token 来代替这些“满天飞”的敏感信息,不就能很大程度上保护敏感信息数据了吗?这样,客户端只需要使用一次凭据数据来换回一个 token,进而通过 token 来访问资源数据,以后就不会再使用凭据了。
客户端凭据模式流程
客户端凭据模式的流程其实跟密码模式相似,整个流程可以归纳为一种步骤:第三方系统通过凭据获取令牌。那么对于系统接口设计来说,是不是一个API接口就可以满足呢?
其实是可以的,比如可以如下定义接口:
请求方式: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不一定要生成返回