共计 2561 个字符，预计需要花费 7 分钟才能阅读完成。
前言
最近有一个简单的需求需要在一个微信公众号外部的 H5 页面中使用微信登录(接入), 同时还要在内部使用第三方支付接口完成支付(不使用微信支付).
无奈队友不给力只好自己研究了一下具体的流程, 不出意料的是这两个接入商提供的 SDK 不同另外微观操作不同, 但是基本流程是相似的.
理解了其中的规则觉得很有意思, 边萌生出了使用简单的几张图片来解释 OAuth2.0 协议的想法.
ps: 素材是使用 note8+autodesk 画的, 合成使用的是 Photoshop, 对于我这种手残真的累死了, 下次能写字就不发图了(҂˘ _˘).
注意: 本文章不是介绍微信以及第三方支付接入具体的实现的文章.
什么是 OAuth2.0 协议(它能干什么)
OAuth（开放授权）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。
那什么是开放授权, 最直接的例子就是在登录一些网站的时候使用第三方账户进行登录, 相信这些场景相信大家都再熟悉不过了.
为什么使用 OAuth2.0 协议
举一个简单的例子.
我们正在维护一个网上商城, 当用户点击购买的时候, 我们想借用第三方支付来向我们账户里打钱, 而不用花巨额的力气再去开发一套支付系统.
现在用户点击付钱了你会哪个选项来提供支付功能呢?
选项 A:
<a href=”www.xxx.com/pay/account/123456″> 点击支付 </a>
这个方法不错, 几乎 0 成本, 可是它有如下的缺陷(使用这种你是认真的吗?):
你不知道用户是否支付成功从而无法确定订单是否完成
你不知道用户输入的金额
你不知道是谁向你支付, 买的什么东西
没有这种可爱的用户(大概吧)
选项 B: 直接和用户索要第三方支付的账户和密码, 然后由后台进行代理购买.
提出这个方案的人简直是天才, 他彻底的解决了无法确认是谁支付的问题, 但是有如下的不足:
传输用户的帐号密码不安全
由上面引发的种种不安全
你不安全(重要)
选项 C: 使用 AUTH2.0 协议.
用户, 第三方平台和我 (服务商) 的想法????
用户
使用第三方账户登录一个新的网站, 对于用户来说无非就是有如下的需求:
懒的注册
想利用这种第三方登入的便利性(例如: 使用 QQ 登入百度网盘的用户免费获取 2T 空间)
第三方平台
那么对于第三方就拿腾讯来说吧, 假如我有一个博客, 要使用 QQ 登入, 对于腾讯来说如何做才能保证用户的安全呢?
首先确认要求接入的服务商提供者的信息资历等(必要的时候可以查水表????)
然后给要求接入的服务商一个唯一凭证, 标明服务商身份
服务商(我)
我们要做的就是将这两者进行连接起来, 而具体的方式如下:
正文
一般来说你会得到如下的两个参数:
appid 代表你的应用唯一 ID
appsecret 对应的密钥
这个部分每家平台都不一样, 具体如何获取你的 APPID 请参考对应平台的指南.
注意: 第三方平台给你的不一定是 APPID, 我的意思不是连名字都完全一样, 有的平台给的参数多有的给的少, 总之都是用于验明身份的.
用户不一定第一次授权就是登录操作, 这里我们以登录为例.
在这个流程中服务器 (我) 接受到了用户想要第三方登录的请求, 我们使用之前获取的 APPID(不同平台叫法和参数可能不同), 然后拼接为成第三方平台指定的 url 然后直接重定向到这个 url.
例如在这个例子中我们的地址可能长这个样子:
www.xxx.com/oauth2.0/authorize?appid=123456&redirect=www.sss.com/login
参数:
appid 我们的应用对于第三方平台的唯一 id
redirect 用户同意授权后被重定向的地址, 一般来说都是本应用的首页或者登录页面, 在本例中就是 www.sss.com/login 这个地址.
其他参数 根据第三方平会有不同的额外参数.
然后将用户重定向到这个 url 中, 此时用户会跳转到 www.xxx.com.
注意: 重定向是一个很重要的参数, 当用户同意授权后第三方服务器将会重定向到这个地址.
这个时候用户被重定向到了 www.xxx.com 上, 页面提示用户是否要向 www.sss.com 进行授权.
如果用户同意了授权, 那么第三方服务器会重定向 url 到我们指定的 url 上, 在本例中就是 www.sss.com/login 并且带上一个 code 参数.
在这个例子中这个 url 看起来是这个样子的:
www.sss.com/login?code=xxxxx
此时我们的 www.sss.com/login 接受到了一个含有 code 的请求, 我们知道这个是一个第三方登录授权后的请求.
我们再次拼接一个 url(不同平台地址规则不同), 但是一般来说这个请求会有如下的参数:
code 用户授权后重定向带回来的 code
appid 应用唯一 id
appsecret 应用对应的密钥
在这个例子中我们请求服务器的 url 可能是这个样子的:
www.xxx.com/oauth2/access_token?appid=xxxx&secert=xxxx&code=xxxx
如果一切顺利在这个阶段我们就可以获取第三方平台响应的一个 accesstoken, 这个 accesstoken 代表着用户对于这个应用的授权.
除此以外你还会获取到用户的基本信息例如用户的唯一 id 之类的.
后续的请求用户的信息需要使用 accesstoken 进行请求.
现在我们来完成用户的登录这个流程.
利用 accesstoken 我们向服务器获取了用户的名字, 显示在了我们的应用中.
后续的资源获取就是这个模式(不同平台资源获取地址以及方式有可能稍有不同).
在用户的资源请求中对于敏感的操作, 都不会在前端中完成, 都是代交由服务器进行资源获取.
注意
用户的会话持久依然是由你来做的, 当用户首次授权登录后你就应该记住用户, 而不是每次登录时候都进行授权.
accesstoken 一般都会有过期时间, 使用一段时间后失效, 所以在某个环节你还可以得到一个 refreshtoken 用于刷新 accesstoken.
参考 & 引用
http://www.ruanyifeng.com/blo… https://www.cnblogs.com/flash… https://blog.csdn.net/hel_wor… https://blog.csdn.net/wang839…
