[简易图解]『 OAuth2.0』 猴子都能懂的图解

一,写在前面的

这两天在看论坛的L03API教程上面的oAuth,对于oAuth这个概念,一直还很模糊,找了很多国内的一些东西看的,当然还有论坛推荐的阮一峰的说明,但是总是感觉有种理不清楚的感觉。
加之国内很多教程对于非计算机专业的人理解不友好。
恰好在日本网站上看到了一些说明特别容易理解。就按照他们的思路自己写了这一段图。
顺便说下,没别的意思,对于IT一些术语的解释,国内还是偏向于专业化了,甚至很多也只是翻译国外的文章,没有自己的理解,还有可能是我。。看的太少了吧。也有可能是我的实力不够。
国外有很多感觉真的是写给猴子看的,还有面向儿童的一些书,很适合我这种刚开始接触某个概念的人来看。

  • 废话不多说了,上图了。这是根据PPT做出来的简图。
  • 如果想一次性看完的,可以去下面这里直接看。
  • 新手理解,不吝赐教。
  • PPT幻灯片

为了不引起歧义补充说明一下,这篇只是很概括的说明了一下什么是OAuth。
真正的授权肯定不是这么简单,到具体的OAuth授权模式上会更加复杂,看完这篇可以看看这篇我总结的授权模式,授权模式总结,比这个稍微没这么好懂一点,但我非计算机专业的我都能懂的话,应该认真看问题不大。本篇文章就不做赘述啦。

二,步骤图

1.我们这里有一份用户的数据

file

2.用户的数据我们保存在资源服务器(Resource server)

file

3.这时候有个 第三方应用程序(Third-party application)想要请求资源服务器要用户数据

file

4.为了让用户数据和第三方程序程序良好的交互,资源服务器准备了一个API接口

file

5.第三方应用程序向资源服务器请求用户的数据

file

6.资源服务器表示好的给你了

file

7.但如果这个第三方应用程序是恶意的第三方呢?那么就会有以下的场景出现

file

8.所以我们需要一个机制来保护API接口,不能随随便便毫无安全可言的把用户的数据送出去

file

9.这个最佳实践就事先在第三方程序里保存一个令牌access_token

file

10.第三方应用程序在向资源服务器请求用户数据的时候会出示这个access_token

file

11.然后资源服务器取出授权码并且验证是否有授权

file

12.授权通过,资源服务器才会把用户数据传递给第三方应用程序

file

13.但这种方案需要事先给第三方access_token

file

14.所以我们需要一个东西用来发行这个access_token,这时候认证服务器 (Authorization server)登场了

file

15.认证服务器负责生成并且发行access_token给第三方应用程序

file

16.接下来我们看一下目前的登场的人物有

  • 第三方应用程序
  • 资源服务器
  • 认证服务器
  • access_token
  • 用户数据

    资源服务器和认证服务器有时候是同一台服务器

file

17.接下来我们来走一下流程 认证服务器生成access_token

file

18.认证服务器发行access_token授权给第三方应用程序

file

19.第三方应用程序拿着access_token去找资源服务器要用户数据

file

20.资源服务器取出来access_token并验证

file

21.验证通过 用户数据送出

file

22. 问题点来了

到上面为止有个很大的问题就是,认证服务器生成access_token竟然没人管!那岂不是随便发行了,这不行,于是我们的用户Resource Owner:资源所有者)出现了!

file

23. 解决

认证服务器在发行access_token之前要先通过用户的同意

24. 于是接下来就是

  1. 第三方应用程序向认证服务器要access_tokenfile
  2. 认证服务器生成之前先问问用户能不能授权啊file
  3. 用户说好的可以给file
  4. 认证服务器生成access_token并且发行给第三方应用程序file

    25. oAuth2.0

    第三方应用程序和这个认证服务器之间围绕着access_token进行请求和响应的等等就是oAuth2.0
    file

本作品采用《CC 协议》,转载必须注明作者和本文链接
⬇︎第一次零基础搭建的个人博客。欢迎批评指正,大力鞭策!❤︎ 旺财的个人博客(⌯¤̴̶̷̀ω¤̴̶̷́)✧ January 17th, 2020
本帖由系统于 5年前 自动加精
chihokyo
《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
讨论数量: 62

:flushed: "可以的 给吧",用户同意授权后应该是授权服务器通过第三方请求时的传递的回调 url 去主动调用第三方接口,然后把 code 给第三方。第三方再通过使用 code 来获取 access_token

5年前 评论

借你的博客又复习了一遍

5年前 评论
chihokyo

@chexj
您好,资源服务器内的验证您看下我发表的关于OAuth的第二篇进阶文章,这里只说了OAuth是什么,具体的授权模式,有四种,建议您看一下第一种授权码模式。估计就可以解答您的问题。

5年前 评论

@Kiddyu 你要知道Oauth2.0协议的授权码模式,第三方应用程序是拿不到用户账号密码的.
"客户端"不能直接登录"服务提供商",只能登录授权层,以此将用户与客户端区分开来。"客户端"登录授权层所用的令牌(token),与用户的密码不同。用户可以在登录的时候,指定授权层令牌的权限范围和有效期。

5年前 评论

@Flourishing 第三方拿不到用户账号密码的前提是,用户是在服务提供商处登录并授权。
我的问题就是,第三方伪造了服务提供商的登录页面,而用户又怎么去验证,自己输入账号密码的页面是服务器提供商的,而不是第三方伪造的钓鱼页面。

5年前 评论

我旁边有个猴子,它还真看不懂

5年前 评论

有一点一直不太明白,用户怎么防止第三方伪造登录授权页获取用户的账号密码呢?
在网页浏览器中还好说,可以提示用户检查网页地址,如果在 app 中,用户是看不到地址的(如掘金 app 的 Github 登录)。其他的地方说到这点都是含糊的一带而过,有人能详细说说吗

5年前 评论
chihokyo

@beatles 哈哈 修改了

5年前 评论

最后一张图是重点

5年前 评论

去日本旅游能不能偷偷去打工啊?日本要外来的打工者吗?

5年前 评论

还好还好,看懂啦,还是比猴子强点!!!

5年前 评论

@王成涛 谢谢分享,正好周末看看

5年前 评论

真的不错,继续加油

5年前 评论
chihokyo

@lcyitar 当然啊 - -

5年前 评论

写的很好

5年前 评论

@Kiddyu 所以你看见没有,市面上百分之九十以上的第三方应用都是采用授权码的模式,就是在培养用户进行授权的时候不用输入账号密码进行授权,常见的第三方登录QQ ,微信, 微博等,用户用快捷登录也无非是这几个.你可以尝试用在知乎里面查看微信,QQ,微博等服务商的授权页面都是用户在它们里面注册的头像以及昵称等信息展示的,这个你钓鱼网站怎么做到,授权页面拿到用户的在微信,QQ,微博等服务商的授权页面里面注册的头像以及昵称等信息展示的?
上面的这是其一.
其二,微信,QQ,微博等用户登录目前都是培养用户进行登录的时候使用声音,手机验证码,扫码等进行登录,这样就没有使用密码登录的说法.登录跳转到授权页面的时候,你在,微信,QQ,微博注册的用户信息例如头像,昵称等都展示在授权页面的.
以上总结的就是授权页面这步很关键,你说的隐患就是当用户本地的微信,QQ,微博等没有登录的情况下会尝试叫用户输入账号密码进行授权,但是对于这种第三方网站进行授权登录,用户在输入微信,QQ,微博等账号后,一定要有一个授权页面,并且这个页面至少要有用户在微信,QQ,微博上的图像以及昵称展示,要是少了这一步,正常用户都会觉得有问题,都会很谨慎.因为,输入账号密码,一般用户下意识还是有些警觉的.还有微信,QQ,微博也会自动登陆上并且也会提示你用它们的账号登录了某某应用.
还有一个细节就是,在做授权登录的时候,无论是安卓还是苹果,都会有一个明显的两个应用间来回跳转的应用间的切换交互流程.这个你根本不好模仿.

授权最关键的一步就是你在授权页展示了用户的微信,QQ,微博上的头像以及昵称,就是这两个才赢得了用户的信任

file

5年前 评论

@Flourishing 看一下掘金 app 的 Github 登录你就明白我的意思了

5年前 评论

谢谢你通俗易懂的文章,你写文章很有耐心呀。想请教一下你的这种耐心是什么训练出来的,你所在的工作和生活环境对你这种耐心的养成影响大吗?

5年前 评论
TigerLin

666

5年前 评论

给你上热门

5年前 评论

@Kiddyu 因为第三方不可能伪造出服务提供商的登入页面的。你再仔细想一想那位回复你的朋友的话就知道了。

5年前 评论

@cupid112 微信登录和qq登录这种肯定都没有问题。可能你们都没试过我说的例子,所以才不清楚我在说什么。

5年前 评论

老哥,你的博客放在哪家的服务器上?怎么这么慢?

3年前 评论
chihokyo (楼主) 3年前
  1. 所以我们需要一个东西用来发行这个 access_token,这时候认证服务器 (Authorization server)登场了

这边的Authorization应该是「授权」的意思吧,「认证」应该是Authentication

我也是看到第二篇[简易图解]『 OAuth2.0』 『进阶』 授权模式总结,才发现不太对劲。

2年前 评论

感谢分享,这个倒是捋清楚了谁是干啥的。

1年前 评论

写的很明白了

2个月前 评论

慕课网也有对 OAuth2.0 的讲解,当个参考 https://www.imooc.com/learn/557

5年前 评论
chihokyo

@郝合心 谢谢支持哦。

5年前 评论
Jennie

:+1:

5年前 评论

一个月左右就这么熟练啦,厉害

5年前 评论
chihokyo

@dengminfeng 一二个月也不快啦。自己领悟能力很低的,论坛好多说 一读就懂的的文章我好多看了都觉得没太懂。。估计领悟能力太低!:joy:

5年前 评论
KayuHo

真的很通俗易懂 :thumbsup:

5年前 评论
Hesunfly

写的不错,感谢分享!

5年前 评论
chihokyo

@韩槑槑
谢谢您的阅读。
您说的这个授权模式是接下来我要图解的oAuth具体的授权模式,内容会更细致和具体。
上面只是粗略了讲述了什么是oAuth,至于具体的四种模式因为略难,对于新人来说刚开始理解概念就是轮廓性质的。
此篇文章不做赘述。

5年前 评论

@chihokyo :joy: 就是感觉读到最后少了一步,"给我code" - "询问用户" - "同意授权" - "给他code" - "给我令牌",就是少了个 "给我code",就刚刚读到最后有点怪怪的没别的意思哈

5年前 评论
chihokyo

@韩槑槑 嗯嗯,懂您的意思。
其实需要code的也就是授权码模式,其他的三种模式下都没有code这一步。
所以从统一的角度来说,是不需要加code的。

5年前 评论

讲得很清晰明了,加油:+1:

5年前 评论

are you a monkey? i'm monkey! :wink:

5年前 评论
chihokyo

@lcyitar 我属猴的

5年前 评论

我就喜欢这种猴子也能看懂的,很形象符合我的大脑构造。我也是属猴的

5年前 评论

写的棒棒的哦,意思理解了

5年前 评论

@chihokyo 你是中国人吗?:snowflake:

5年前 评论

24.1 资源服务器向认证服务器要access_token……貌似笔误?因为图画上面画的是第3方程序向认证服务器要access_token的……总之这组图画得很好懂!终于理解了访问令牌的存在意义了。感谢博主的分享!

5年前 评论
chihokyo

@zhaiduting
谢谢您的提醒,已经修改好了。
多谢鼓励,愿图解有助于您的理解。

5年前 评论
QIN秦同学

老哥。多发文章啊。关注你了。你这弄得简单易懂、很好、赞一个、

5年前 评论
chihokyo

@echofree313 其实我是女生。。。谢谢鼓励。会继续有的。

5年前 评论

PPT幻灯片链接挂啦,google doc

5年前 评论
chihokyo

@两说 我这里显示的没有问题哦 您翻墙了吗?

5年前 评论

想问一下,资源服务器是如何判断 access_token 有效的?

5年前 评论

通俗易懂,超赞~~~

5年前 评论

灵魂流程图,不过真的简单易懂。

5年前 评论

大家好我是猴子我听懂了

5年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!