结合豆瓣第三方登录理解 OAuth2.0 授权码方式
前言
最近在学习 Spring-Security-Oauth2 ,在此之前必然要研究下 oauth2.0 协议规范。
关于 oauth2.0 的相关概念及理解,这里推荐阅读以下文章:
-
oauth2.0 入门文章
需要声明的是这 2 篇文章中有些错误,主要是关于 redirect_uri 部分,评论区有人已经指出了错误,所以阅读时,请结合评论区内容。(是的,你没看错,即使有错误也是强烈推荐阅读。)
-
oauth2.0 进阶篇
The OAuth 2.0 Authorization Framework
这两篇文章可以放在本文之后去看
而本文的会通过一个案例 - 通过第三方(微博)去登录豆瓣,去分析oauth2 的 授权码模式。
整个流程可以亲自去 豆瓣 实验一下,篇幅原因整个登录流程就不贴图演示了,
另外,豆瓣在这个过程中加上了绑定手机号(现在大多数平台都这么干),这个过程我们忽略过去。
在阅读正文之前,就假设已经理解了 oauth2.0 入门的相关概念(4 种方式,授权码模式的流程以及各个参数含义)。
正文
强调一下,本文只是尝试站在合理的角度去分析豆瓣的第三方登录,如有错误,还请及时指出。
1. 第三方登录流程
先来描述下用户 肉眼 看到的豆瓣第三方登录的流程。
-
用户通过浏览器进入豆瓣官网, 选择微博登录,进入一个微博登陆页面
-
用户输入自己的微博账号和密码,点击授权并登录
-
进入绑定手机号的页面(这一步跳过,假装没有)
-
登录成功,页面右上角显示用户的微博昵称
2. 规范中的通用流程
上面是 OAuth 2.0 框架协议规范中抽象出来的授权流程图
里面涉及到 4 个角色:
- Client(豆瓣)
- Resource Owner(用户本人,用户掌握着自己的微博账号和密码)
- Authoriztion Server (微博授权服务,鉴权,颁发 code, token)
- Resource Server(微博资源服务,保管用户的微博信息(比如:昵称))
3. 规范中的授权码流程
上面的流程图描述的是 oauth2.0 授权码模式的整个流程,整个流程截止到 Client 拿到 access_token.
因此较于之前的流程少了一个 资源服务器 的角色,而本图中的 User-Agent 所表示的角色就是浏览器。
我们可以清楚的看到图中有两个 A ,B,C
-
左边 的用 A1 和 B1 ,C1表示
-
右边 的用 A2 和 B2 ,C2 表示
整个流程的文字描述如下:
-
A1 - B1- C1
浏览器作为 代理 是整个流程的发起者和桥梁,用户首先会通过浏览器在豆瓣官网,选择第三方登录方式
-
A2
当用户选择了微博登录时,页面跳转到微博提供的第三方登陆页面
https://api.weibo.com/oauth2/authorize?redirect_uri=https%3A//accounts.douban.com/connect/sina_weibo/callback& response_type=code& client_id=1994016063
上面的 url 参数是简化过的,我们提取出比较重要的3 个参数,这些参数的具体含义不再细讲
-
client_id
表示 client 的身份是 豆瓣
-
response_type
表示授权码模式
-
redirect_uri
这个参数的作用也是为了做一些验证,阮一峰的文章中关于这一点的说明是错误的,当然评论区有正确答案,更详细的内容请参考 关于 OAuth2.0 安全性你应该要知道的一些事
-
-
B2
用户输入微博账号和密码,点击“授权并登录”
-
C2
微博授权服务器认证用户身份成功后,返回一个授权码 code 给 豆瓣
-
D
豆瓣拿到授权码,再加上 redirect_uri 等参数,再次发送请求到微博授权服务器
-
E
微博授权服务器返回 access_token 给豆瓣, 最终豆瓣就可以通过 access_token 去获取受限访问的微博用户信息。
总结
本文通过粗略分析 豆瓣 的第三方登录流程,来加深我们对规范中流程图的理解。
熟悉整个 oauth2.0 协议规范,大致需要了解一下内容:
-
oauth2.0 的概念及作用
-
4 种方式
-
模式中涉及到的参数含义
-
安全性问题
-
结合具体案例分析流程
当我们掌握了以上内容后,再去理解 Spring-Security-Oauth2 框架,会容易得多。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
换一种方式编写 Spring MVC 接口
1. 前言 通常我们编写 Spring MVC 接口的范式是这样的: @RestController @RequestMapping("/v1/userinfo") public class UserInfoController { @GetMapping("/foo") public String foo() { return "felord.cn"; } } 这种我都写吐了,今天换个口味,使用 Spring 5 新引入的函数式端点(Functional Endpoints)来耍耍。 这种方式同样支持 Spring Webflux。 请注意可使用该特性的 Spring 版本不低于 Spring 5.2 2. 依赖 为了演示,这里极简化只引入 Spring MVC 的 starter : <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency...
- 下一篇
Apache RocketMQ 的 Service Mesh 开源之旅
作者 |凌楚阿里巴巴开发工程师 导读:自 19 年底开始,支持 Apache RocketMQ 的 Network Filter 历时 4 个月的 Code Review(Pull Request),于本月正式合入 CNCF Envoy 官方社区(RocketMQ Proxy Filter 官方文档),这使得 RocketMQ 成为继 Dubbo 之后,国内第二个成功进入 Service Mesh 官方社区的中间件产品。 Service Mesh 下的消息收发 主要流程如下图: 图 1 简述一下 Service Mesh 下 RocketMQ 消息的发送与消费过程: Pilot 获取到 Topic 的路由信息并通过 xDS 的形式下发给数据平面/Envoy ,Envoy 会代理 SDK 向 Broker/Nameserver 发送的所有的网络请求; 发送时,Envoy 通过 request code 判断出请求为发送,并根据 topic 和 request code 选出对应的 CDS,然后通过 Envoy 提供的负载均衡策略选出对应的 Broker 并发送,这里会使用数据平面的 su...
相关文章
文章评论
共有0条评论来说两句吧...