![773f17b7bd2108b62fb6607292171284.png](https://i-blog.csdnimg.cn/blog_migrate/0fa3d57518cc1fe2f1ff185aa184705c.jpeg)
一 OAuth2.0协议的基本概念
(1)OAuth2.0协议
OAuth协议,是一种授权协议,不涉及具体的代码,只是表示一种约定的流程和规范。OAuth协议一般用于用户决定是否把自己在某个服务商上面的资源(比如:用户基本资料、照片、视频等)授权给第三方应用访问。此外,OAuth2.0协议是OAuth协议的升级版,现在已经逐渐成为单点登录(SSO)和用户授权的标准。
不知道大家有没有发现,目前主流的互联网网站除了可以使用“用户名+密码”模式和“手机号+验证码”模式登录外,很多还提供了第三方账号登录,比如最常见的QQ登录、微博登录、百度账号登录、GitHub登录。而这些第三方登录方式就是采用了OAuth2.0协议实现。
![fbd03f58b4057ef7d35fd378c2b7142b.png](https://i-blog.csdnimg.cn/blog_migrate/792961bc6f97bf6a5c7d1392d18a4f28.jpeg)
(2)为什么使用OAuth2.0协议?
第一,用户不再需要注册大量账号。在以前,我们每使用一个新的网站或者APP就需要注册一个账号,建立一套新的账户体系才能使用网站 / APP提供的服务。但是现在我们只需要拥有几个主流应用的账号,然后通过他们提供的第三方账号登录就可以使用一个新的网站/APP了(当然,我们也可以不使用腾讯百度等公司提供的授权服务,开发自己的授权服务端,这方面的内容我将放在下篇文章中介绍)。
第二,用于单点登录。如果某个公司有很多个需要用户登录才能提供服务的子产品(比如:官网、M网站、APP、微信公众号、使用同一套账户体系的产品1、产品2等等),这种情况下为每个产品都开发一个登录、授权模块显然是不太优雅,因此比较好的解决方案就是所有需要登录的产品都请求同一个登录授权中心,进行统一登录授权处理。而OAuth2.0协议就可以实现符合上述要求的单点登录功能。
第三,用于分布式系统的权限控制。因为基于OAuth2.0协议获得的令牌(Access Token)同时关联了接入的第三方应用、授权用户、权限范围等信息。因此,在第三方应用拿着Token请求资源的时候,资源服务应用就可以很容易根据其访问权限返回相应的数据。
(3)OAuth2.0协议涉及到的几个重要角色
- 授权服务端应用(Authorization Server):服务提供商提供的专门用于处理授权的服务端应用,比如上面介绍的QQ登录、微博登录,当然也可以搭建自己的授权服务端。
- 资源服务应用(Resource Server):服务提供商存放用户及其他资源的应用,一般用于接口的形式返回第三方应用请求的资源。它可以与授权服务端属于同一个应用,也可以分别属于不同的应用。
- 用户(User):用户在授权服务端登录,授权服务端记录了用户的账户体系。当然,有的网站会在你通过第三方账号第一次登录成功后,要求绑定你的手机号并创建昵称,这就是他们在创建自己的账户体系(跟OAuth2.0协议无关,这里不作展开)了。
- 接入的第三方应用(Third-party Application):接入认证的第三方应用又被称为“客户端”,比如一个普通的网站、APP。
(4)几种授权模式
- 授权码模式(authorization code):这是功能最完整,流程最严密的模式。现在主流的使用OAuth2.0协议授权的服务提供商都采用了这种模式,我在下面举例也将采取这种模式。
- 简化模式(implicit):跳过了请求授权码(Authorization Code)的步骤,直接通过浏览器向授权服务端请求令牌(Access Token)。这种模式的特点是所有步骤都在浏览器中完成,Token对用户可见,且请求令牌的时候不需要传递client_secret进行客户端认证。
- 密码模式(resource owner password credentials):用户向第三方客户端提供自己在授权服务端的用户名和密码,客户端通过用户提供的用户名和密码向授权服务端请求令牌(Access Token)。
(5)授权码模式(authorization code)授权的流程
采用Authorization Code获取Access Token的授权验证流程又被称为Web Server Flow,适用于所有有Server端的应用,如Web/Wap站点、有Server端的手机/桌面客户端应用等。一般来说总体流程包含以下几个步骤:
- 通过client_id请求授权服务端,获取Authorization Code。
- 通过Authorization Code、client_id、client_secret请求授权服务端,在验证完Authorization Code是否失效以及接入的客户端信息是否有效(通过传递的client_id和client_secret信息和服务端已经保存的客户端信息进行匹配)之后,授权服务端生成Access Token和Re