轻松理解OAuth2.0协议(多图)

前言

最近有一个简单的需求须要在一个微信公众号外部的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咱们向服务器获取了用户的名字,显示在了咱们的应用中.

后续的资源获取就是这个模式(不一样平台资源获取地址以及方式有可能稍有不一样).

在用户的资源请求中对于敏感的操做,都不会在前端中完成,都是代交由服务器进行资源获取.

注意

1. 用户的会话持久依然是由你来作的,当用户首次受权登陆后你就应该记住用户,而不是每次登陆时候都进行受权.
2. accesstoken通常都会有过时时间,使用一段时间后失效,因此在某个环节你还能够获得一个refreshtoken用于刷新accesstoken.

参考&引用

http://www.ruanyifeng.com/blo...
https://www.cnblogs.com/flash...
https://blog.csdn.net/hel_wor...
https://blog.csdn.net/wang839...