微服务架构实战 160 讲
杨波
拍拍贷研发总监、资深架构师、微服务技术专家
48732 人已学习
新⼈⾸单¥98
课程目录
已完结/共 171 讲
微服务架构实战 160 讲
登录|注册
留言
2
收藏
沉浸
阅读
分享
手机端
回顶部
当前播放: 167 | Demo展示(lab05)(上)
00:00 / 00:00
高清
  • 高清
1.0x
  • 2.0x
  • 1.5x
  • 1.25x
  • 1.0x
  • 0.75x
  • 0.5x
网页全屏
全屏
00:00
付费课程,可试看
01 | 第一模块课程介绍
02 | 微服务安全要解决什么问题
03 | 白话 OAuth2
04 | OAuth2 的正式定义
05 | OAuth2 有哪些典型模式
06 | OAuth2 模式该如何选型
07 | Spring Security OAuth2 架构简介
08 |【实验】授权码模式授权服务器
09 |【实验】简化模式授权服务器
10 |【实验】密码模式授权服务器
11 |【实验】客户端模式授权服务器
12 | 实验一扩展环节
13 |【实验】Web 应用接入授权服务器
14 | 实验二扩展环节
15 | 什么是 JWT 令牌
16 |【实验】授权服务器支持 JWT 令牌
17 | 实验三扩展环节
18 |【实验】Android 无线应用接入授权服务器
19 |【实验】AngularJS 单页应用实验和课后扩展
20 |【实验】GitHub社交登录实验和课后扩展
21 | 【实验】OAuth2安全风险CSRF实验
22 | OpenId Connect简介
23 | 下一代微服务安全架构
24 | 参考资源和后续课程预览
25 | Apollo作者的产品介绍
26 | 第二模块课程介绍
27 | 课程概述
28 | 业务需求
29 | 配置定义和场景
30 | 开关驱动开发原理
31 | 携程 Apollo 配置中心介绍
32 | Apollo核心概念
33 | Apollo快速起步(Lab01)
34 | Apollo快速起步扩展实验
35 | Apollo架构设计之服务器端
36 | Apollo架构设计之客户端
37 | Apollo架构设计之高可用和监控
38 | Apollo分布式部署指南
39 | Apollo Java客户端和多语言接入
40 | Apollo Client API实操(Lab02)
41 | Apollo Client和Spring集成~XML方式(Lab03)
42 | Apollo Client和Spring集成~代码方式(Lab04)
43 | Apollo Client和Spring Boot集成(Lab05)
44 | Apollo开放平台接入实操(Lab06)
45 | Spring Cloud Config简介
46 | Apollo vs Spring Cloud Config
47 | Apollo FAQ和开发常见问题
48 | 参考资源和后续课程预览
49 | 第三模块课程介绍
50 | Zuul网关和基本应用场景
51 | Zuul网关高级应用场景
52 | Zuul网关架构剖析
53 | Zuul网关代码剖析(Code Review)
54 | Zuul网关过滤器管理工具(Code Review)
55 | 前置过滤器实验(Lab01)
56 | 路由过滤器实验(Lab02)
57 | 后置过滤器实验(Lab03)
58 | Zuul网关对接Apollo(Lab04)
59 | Zuul网关生产部署实践
60 | Zuul网关路由管理实践
61 | 基于网关的两层路由体系
62 | Spring Cloud Zuul(Lab05)
63 | Zuul2.0简介
64 | Zuul网关生产最佳实践
65 | 参考资源和后续课程预览
66 | 第四模块课程介绍
67 | 调用链监控业务需求
68 | 调用链监控原理
69 | 调用链监控产品和比较
70 | 点评 CAT 背景介绍
71 | CAT 典型报表
72 | CAT 告警简介
73 | CAT 架构设计
74 |【实验】CAT 本地部署
75 | CAT 埋点案例和代码剖析(Code Review)
76 |【实验】CAT 埋点案例
77 | Zuul 网关集成 CAT 代码剖析(Code Review)
78 |【实验】Zuul 网关集成 CAT
79 | CAT 生产埋点实践
80 | CAT 生产部署实践
81 | CAT 生产治理实践
82 | Spring Cloud Sleuth 简介
83 |【实验】Spring Cloud Sleuth
84 | 参考资源和后续课程预览
85 | 第五模块课程介绍
86 | 容错限流需求
87 | 容错限流原理
88 | Netflix Hystrix 背景介绍
89 | Hystrix 设计原理
90 | Hystrix 主要概念
91 | 信号量 vs 线程池隔离
92 | Hystrix 主要配置项
93 |【实验】Hystrix 基础实验
94 | Hystrix 模拟案例分析 (Code Review)
95 |【实验】Hystrix + Dashboard 实验(上)
96 |【实验】Hystrix + Dashboard 实验(下)
97 | 网关集成 Hystrix (Code Review)
98 |【实验】Spring Cloud Hystrix 实验
99 | Netflix Turbine 简介
100 | Hystrix 生产最佳实践
101 | 参考资源和后续课程预览
102 | 第六模块课程介绍
103 | 服务发现需求和模式(上)
104 | 服务发现需求和模式(下)
105 | Netflix Eureka 和 Ribbon 背景介绍
106 | Eureka 和 Ribbon 架构设计原理
107 |【实验】Spring Cloud Eureka 和 Ribbon 基础实战
108 |【实验】Spring Cloud Eureka 和 Ribbon 高级实验
109 | Spring Cloud Eureka 和 Ribbon 主要配置项
110 | Eureka进阶:自保护模式
111 | Eureka进阶:健康检查和蓝绿部署
112 |【实验】Spring Cloud Zuul、Eureka 和 Ribbon 集成实验(上)
113 |【实验】Spring Cloud Zuul、Eureka 和 Ribbon 集成实验(下)
114 | 常用服务发现组件比较
115 | ServiceMesh 和 Istio 简介
116 | 基于 Eureka、Zuul 和容器云的持续交付架构
117 | 参考资源和后续课程预览
118 | 第七模块课程介绍
119 | 监控模式分类
120 | BusDevOps 和测量驱动开发 MDD
121 | Prometheus 简介
122 | Prometheus 架构设计
123 | Prometheus 基本概念
124 |【实验】Prometheus 起步查询实验(上)
125 |【实验】Prometheus起步查询实验(中)
126 |【实验】Prometheus起步查询实验(下)
127 |【实验】Prometheus + Grafana 展示实验(上)
128 |【实验】Prometheus + Grafana 展示实验(下)
129 |【实验】Prometheus + Alertmanager 告警实验(上)
130 |【实验】Prometheus + Alertmanager 告警实验(下)
131 |【实验】Java 应用埋点和监控实验
132 |【实验】NodeExporter 系统监控实验
133 |【实验】Spring Boot Actuator 监控实验
134 | Prometheus 监控最佳实践
135 | 主流开源时序数据库比较
136 | 开源分布式监控平台 ZMon 简介
137 | 微服务监控体系总结
138 | 参考资源和后续课程预览
139 | 课程概述和背景
140 | 架构和设计
141 | 开发环境搭建
142 | 基础代码(code review)
143 | 数据访问模块(code review)
144 | OAuth2服务模块(code review)
145 | Web服务模块(code review)
146 | 启动流程(code review)
147 | 起步准备实验(lab02)
148 | OAuth2授权码模式实验(lab03)
149 | OAuth2简化模式实验(lab04)
150 | OAuth2用户名密码模式实验(lab05)
151 | OAuth2客户端模式实验(lab06)
152 | OAuth2令牌校验实验(lab07)
153 | OAuth2令牌刷新实验(lab08)
154 | 项目复盘和扩展环节
155 | 参考资源和后续课程预览
156 | 课程概述和背景
157 | 需求和架构设计
158 | 开发环境搭建(lab01)(上)
159 | 开发环境搭建(lab01)(下)
160 | 项目业务代码(Code Review)
161 | Apollo配置中心集成(lab02)
162 | Zuul-Eureka-Ribbon-Hystrix集成(Code Review)
163 | Gravitee OAuth2集成(lab03)
164 | Zuul网关集中令牌校验(Code Review)
165 | CAT调用链集成(lab04)(上)
166 | CAT调用链集成(lab04)(下)
167 | Demo展示(lab05)(上)
168 | Demo展示(lab05)(下)
169 | Prometheus监控集成(Code Review)
170 | 生产扩展环节
171 | 课程复盘总结&结课测试
登录 后留言

全部留言(2)

  • 最新
  • 精选
DDs moving castle
波波老师,像piggymetrics演示项目这样在申请令牌时将Client客户端凭证写在ajax的js中,我感觉也是很不安全的,毕竟客户端凭证也是一种校验,请问生产级别应如何处理? 1、clientId和sercet保存在哪儿比较安全(生产级别)? 2、令牌申请后存储在哪儿比较安全(生产级别)? 3、我看之前的留言中说,授权码模式下令牌是在服务器端的??指的是access token和refresh token都在服务器端吗?那下次ajax如何携带access token? 对OAuth2的授权流程已经基本了解,但还是有些想不清楚,比如前后端分离的场景下,Client客户端凭证应保存在哪儿,zuul网关作为申请令牌的Client保存?前端的Nginx服务器?还是单独的一个web服务器?感觉放在前端js中,浏览器F12就能获取到是不安全的。 还有申请令牌后应存放在哪儿,access token是肯定要给浏览器的,用于下次访问时携带,有效期较短,可如果refresh token也给浏览器放在LocalStorage,一旦被截获,就更不安全了。 关于上面这类问题,在不同的场景下生产级别怎么处理比较安全能不能专题分享一下。我感觉这也是一个扩展点。

作者回复: 你好,谢谢你的反馈问题,按照最初的OAuth2规范,SPA单页应用建议是使用简化(Implicit)模式的,这种模式下,应用只传clientId,不传secret,而且获取的令牌也是放在浏览器端(一般是localstorage)的。因为这种模式安全性比较弱,所以一般只限于安全不严格的有限场景。 OAuth2 6749规范制定时间比较早,现在单页SPA开始流行起来,所以这个规范也一直在修订,有些补充规范提出SPA可使用一种授权码+PKCE模式,但我看过应用端实现比较复杂,且对AuthServer有要求,可参考一篇较新文档(https://auth0.com/blog/oauth2-implicit-grant-and-spa/)。 对于正式的授权码模式,令牌会存在Web服务器上,它和后台API交互是会使用令牌,用户浏览器中没有令牌(因为它不直接和后台API交互),浏览器和Web服务器之间可以有Session,而且这个Session可以和某个令牌关联。 如果你要使用单页SPA,又想比较好的安全性,推荐一种oauth-proxy做法,相对比较简单,这个oauth-proxy作为代理,可以让单页SPA实现授权代模式,而且简单可靠,具体做法参考这里的github站点代码(https://github.com/madumalt/oauth-proxy),这做法其实通过扩展网关也可以实现,它可以做到令牌存proxy端(有状态),也可以用加密cookie方式(无状态),而且不会在SPA应用中暴露clientId/secret。

2019-04-01
2
1
DDs moving castle
首先谢谢波波老师的回复,推荐的文章及项目对我很有帮助。其实我和同事也讨论在zuul网关上实现OAuth的Client的功能,虽然我心里还是角色SPA是真正的Client,但可以把zuul网关理解为Client的外延,和你提供的oauth-proxy做法很类似。 oauth-proxy项目我大概看了,它是在浏览器与oauth-proxy之间维持cookie-session,使用oauth-proxy作为OAuth Client获取令牌,获取令牌后,可以不下发给浏览器,cookie与令牌映射关系(有状态),或者加密后放到cookie里下发给浏览器(无状态)。但我有点不明白无状态下,为啥还要加密令牌??我理解这两种下发的形式都是利用了浏览器对cookie的一些安全机制,因为整个oauth-proxy是解决了client凭证存放在哪儿的问题,已经获取token也存放在oauth-proxy,但对于浏览器与oauth-proxy之间,cookie中的内容加密可以放篡改,而不能放窃取,就能JWT的签名一样,而放窃取我感觉是更难也更重要的。 你推荐的文章我也大概看了(全英文还是挺费力啊),给我感觉OAuth2协议只定义了它4个角色之间怎么安全的获取令牌,校验令牌,但对于现在常用的user-agent(浏览器),OAuth2涉及的不多,或者说它说了也不算,比如google就不想支持token绑定。而文章中给出的一些其它方案:(1)same-site cookie,我感觉对于我们公司这种域名不在Public Suffix List里的应该用不了吧??(2)PKCE,实现起来复杂,而且好像只在获取token环境增加了code exchange,而校验token还是无法校验是不是黑客在使用。(3)我也简单看了pop令牌,也是用于OAuth Client与授权服务器之间证明是真正Client请求而不是黑客的,和Browser感觉没什么关系。 其实我们公司就是想做前后端分离的应用,可能内部用,也可能公网用,但越看越觉得2012年发布OAuth2设计的Client是一个web server,如果场景是开发平台供第三方授权访问API很合适,但是对于基于浏览器的应用,OAuth2一开始设计的比较简单,对于Browser与OAuth Client之间比较少,后来做扩展的时候也需要各浏览器厂商的支持,目前也没完全成型,所以从浏览器到OAuth Client的安全,还是基于原来的浏览器对cookie-session的安全机制,用token存localstorage可能还没有cookie安全。这就让我产生了一个疑惑,基于浏览器的有必要用OAuth2吗??传统的user/passwd+https+SSO的模式不也一样吗,都要依靠cookie的存储和https的传输时安全。从浏览器到zuul网关后,基本就是偏内网环境了,zuul作为Client和授权服务器之间都是内网,走什么授权模式或者传统模式都差不多了。 不知道我的理解对不对,请波波老师指点。

作者回复: 你好,oauth-proxy主要解决两个问题,一个是将clientid/secret存服务端,保证client验证并且不泄露secret,二是token不流到浏览器端,减少token暴露泄露风险,但是为了实现无状态校验(让token不用存储在服务端,否则需要关联sessionId和查询token很麻烦),所以将token存浏览器cookie,但这又会造成token泄露问题,所以必须加密。 OAuth2主要针对分布式微服务/API场景,特别是开放API,这个时候传统username/password方式就明显不合适了。 传统Web应用基于cookie-session实现登录认证和SSO很普遍也很成熟,未必需要用OAuth2,当然现在有OpenID Connect(在OAuth2基础上构建的轻量身份认证协议)也可以实现登录认证和SSO。 如果你深入下去,不管是Web Session/cookie还是OAuth2/token发现这些机制底层相通,无非是身份权限状态存储和引用标识的问题,达成目标的形式稍有不同而已。你可以根据自己的场景灵活选择,未必需要拘泥,当然安全有个最佳实践,尽量遵循标准保证安全性、扩展性和互操作性,这也是Google/Facebook等大厂一般做法。 另外,SPA也可以用增强的授权码模式,不少授权服务器提供js封装,可以直接应用,例如idenityserver(https://github.com/IdentityModel/oidc-client-js),还有keycloak应该也有js adapter。

2019-04-08
收起评论