目录
一、前言
随着企业信息系统的运营及发展，与外围平台间的数据共享越来越密切，越来越多的企业信息系统将内部核心数据资源，提供给第三方或内部跨部门系统接入，便于共同开发数据资源。那么设计一个开放平台除了构建核心数据资源外，在系统接入时的认证和授权也是开发技术平台主要组成部分。关于系统之间的认证、授权，目前主要流行使用OAuth2.0协议作为支撑，如现在的百度开放平台、腾讯开发平台等。本文主要通过对OAuth2.0协议的阐述，以便读者可快速解读、使用第三方开放平台以及作为自我构建开放平台的参考。
二、认证与授权
认证：解决你是谁的问题；
授权：解决你能干什么。
对于微博、微信开放平台接入时，当第三方应用信任并接受微博或微信的身份证凭证，就可以使用该凭证直接登录第三方应用，此时，开放平台完成认证功能，而关于通过该凭证能在第三方做什么，则由第三方应用系统根据自己策略进行授权控制。
开放平台认证成功后，凭证可以是用户名、手机号、身份证号或加自定义字符等，但对于开放平台而言，授权第三方应用时，并不想让第三方系统可以获取到诸如手机号、身份证号等关键信息，故此会引入OpenID作为用户身份证认证。下面引用百度百科对OpenID解释：
OpenID 是一个以用户为中心的数字身份识别框架，它具有开放、分散性。OpenID 的创建基于这样一个概念：我们可以通过 URI （又叫 URL 或网站地址）来认证一个网站的唯一身份，同理，我们也可以通过这种方式来作为用户的身份认证。
如，对于微信公众平台而言，OpenID是微信用户自公众号appid下的唯一用户识别（appid不同，则获取到的OpenID就不同），可以用于永久标记一个用户。OpenID是一个没用特别含义的字符串，但该值可通过平台获取到平台给予开放的不关键或给予范问的相关信息，由此可见OpenID侧重于身份证认证。
开放平台除了身份证认证外，同时也具有自己的授权控制策略，以主流OAuth2.0为主：
OAuth（Open Authorization，开放授权）是一个开放标准，允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容。
OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站在特定的时段内访问特定的资源。
三、OAuth2.0协议
OAuth2.0协议作为用户资源的授权，提供了一个当前较为安全的、开放又简易的标准。
OAuth2.0定义了授权码模式（Authorization Code）、简化模式（Implicit）、用户名密码模式（Resource Owner Password Credentials）、客户端凭证模式（Client Credentials）四种授权模式。
（一）客户端凭证模式
(1)、客户端向授权服务器申请授权；
(2)、授权服务器返回一个Access Token；
(3)、用Access Token去访问资源服务器；
(4)、资源服务器返回资源。
1．特点
l 不需要用户参与；
l 不支持Refresh Token。
2．使用场景
l 使用了第三方的静态文件服务；
l 适用于服务器间通信场景。
（二）用户名密码模式
(1)、用户把用户名和密码交付给客户端；
(2)、客户端通过用户提交的用户名和密码向授权服务器进行授权申请；
(3)、申请成功时，返回一个Access Token；
(4)、用Access Token去访问资源服务器；
(5)、资源服务器返回资源。
1．特点
l 支持Refresh Token；
l 容易暴露用户的信息。
2．使用场景
l 第一方原生App或单页面应用；
l 认证作为拥有系统子模块使用。
（三）授权码模式
以微信开放平台统一登录为例
(1)、微信用户通过浏览器访问并且用微信登录第三方应用，客户端（Client）会跳转到微信的登录授权界面；
(2)、微信用户通过扫码进行授权申请；
(3)、授权成功之后，授权服务器（微信开放平台）将用户导向事先指定的重定向URI，同时附上一个授权码（Authorization Code）；
(4)、客户端收到授权码， 并附上已有的重定向URI，向授权服务器申请Access Token。（这一步是在对用户不可见）；
(5)、授权服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（Access Token）和更新令牌（Refresh Token）和Token有效时间。
1．特点
l 支持Refresh Token；
l 通过Authorization Code来获取Access Token。
2．使用场景
l 适用于所有有Server端的应用，如Web站点、有Server端的手机客户端，如微信开放平台的统一登录等。
（四）简化模式
以访问唯品会为例子
(1)、用户访问唯品会，然后唯品会要求用户登录，并且向用户显示可以支持QQ 、支付宝、微信、微博、网易等登录方式。假如选择是QQ，则跳转到QQ界面（用户代理），如果用户还未登录，则要求用户登录QQ,如果已经登录，则会提示点击QQ头像进行授权和获得那些权限；
(2)、用户点击授权进行申请；
(3)、授权成功之后，QQ认证服务器将用户导向唯品会事先指定的重定向URI，同时附上一个Access Token；
(4)、QQ界面（User-Agent）收到重定向响应后，向唯品会服务器提出请求，表示想提取URI中的Access Token；
(5)、唯品会服务器返回带有解析脚本的页面，用于解析重定向URI Fragment中的Access Token；
(6)、User-Agent使用解析脚本，获取Access Token；
(7)、User-Agent将Access Token转交给唯品会。
1．特点
l 不支持Refresh Token；
l 比授权码模式少了Authorization Code环节，利用回调url直接携带 Access Token。
2．使用场景
l 适用于无Server端配合的应用，手机/桌面客户端程序、浏览器插件；
l 基于JavaScript等脚本客户端脚本语言实现的应用；
l 基于浏览器的应用等。
四、总结
部分企业或开源架构对各模式实现针对实际应用场景做相对应的调整，如Refresh Token的支持。
OAuth2.0关注客户端开发者的简易性，同时为Web应用，桌面应用和手机等提供专门的认证流程。那如何根据不同的场景选择相应的授权模式进行授权。笔者做出如下总结：
1、客户端凭证模式：访问的令牌拥有人是机器，如：服务器见通信场景等；
2、用户名密码模式：访问的令牌拥有这是单页面应用SPA的第一方客户或者是原生App第一方客户；
3、授权模式：访问的令牌拥有这是web服务器应用或者是原生App第三方客户；
4、简单模式：访问的令牌拥有这是单页面应用SPA的第三方客户。
470
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
