上一节介绍过什么是OAuth2,这节准备用生动的事例来告诉大家OAuth2运行的流程。
我们来想这样一个场景:假设我们有一个叫做万方网盘的服务是用来帮助用户存储论文文档的,我们向外提供了Api,可以让第三方程序获取到用户的论文。我们用了一个符合OAuth2标准的授权服务来管理Api的授权。有一个第三方的程序可以调用我们平台的接口获取用户论文,来帮助用户投稿。
在OAuth2中,我们管用户叫做资源拥有者(ResourceOwner,RO),投稿应用叫做Client,万方网盘叫做资源服务(ResourceServer,RS),最后我们还有一个授权服务(AuthorizationServer,AS)。
以下是OAuth2的基本运行流程:
、ResourceOwner向Cilent发出某个请求,这个请求需要调用ResourceServer的用户资源。
1、Client为了能够拿到用户的资源,就要先获取用户的授权。
2、client拿着用户授权向AuthorizationServer请求访问令牌(AccessToken)
3、然后client再拿着访问令牌去向ResourceServer获取用户资源
这就是一个完整的OAuth2流程。放一张官方的图给大家看:
其实当第一次完成A到D的四个步骤之后,client再要去请求资源的时候,就直接拿着AccessToken去请求就可以了,不需要每次都进行A到D四个步骤。因此,我们发现在这个过程中AccessToken会经常的被传输,越是经常被网络传输的信息就越容易泄漏,因此AccessToken的有效时间就要设置的短一些。但是如果因为AccessToken的有效期短,导致了频繁向用户请求授权,这是一件用户体验很差的事情,为了解决这个问题,OAuth2引入了Refresh Token。
当Client得到用户授权之后,向授权服务器获取授权的时候,授权服务器不止会给Client一个AccessToken还会给一个Refresh Token用以换取新的AccessToken。当Client请求资源服务器之后,如果发现原本合法的AccessToken失效了(步骤E到F),就会用RefreshToken向授权服务器再请求一个新的Access Token,授权服务器会将新的AccessToken和新的RefreshToken发送给Client(步骤G到H)。由于有了RefreshToken,Client在向授权服务器请求AccessToken的时候就可以不需要再次向用户请求授权了。同样的,因为RefreshToken很少用于传输,所以它是安全的。
以上就是OAuth2的基本运行流程,下一章将会向大家介绍OAuth2的四种模式。
领取专属 10元无门槛券
私享最新 技术干货