当前播放: 23 | 下一代微服务安全架构
00:00 / 00:00
高清
  • 高清
1.0x
  • 2.0x
  • 1.5x
  • 1.25x
  • 1.0x
  • 0.5x
网页全屏
全屏
00:00
付费课程,可试看
课程目录
第一模块 :微服务安全架构与实践 (24讲)
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 | 参考资源和后续课程预览
第二模块 :微服务配置中心Apollo架构和实践 (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 | 参考资源和后续课程预览
第三模块 :微服务网关Zuul架构和实践 (17讲)
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 | 参考资源和后续课程预览
第四模块 :微服务调用链监控CAT架构和实践 (19讲)
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 | 参考资源和后续课程预览
第五模块 :微服务容错限流Hystrix架构和实践 (17讲)
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 | 参考资源和后续课程预览
第六模块 :微服务注册发现Eureka Ribbon架构和实践 (16讲)
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 | 参考资源和后续课程预览
第七模块 :微服务监控告警Prometheus架构和实践 (21讲)
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 | 参考资源和后续课程预览
第八模块 : 构建OAuth2服务器 - Golang语言实现 (17讲)
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 | 参考资源和后续课程预览
第九模块:微服务架构综合案例分析 (16讲)
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 | 课程复盘总结
23 | 下一代微服务安全架构

23 | 下一代微服务安全架构

杨波
拍拍贷研发总监、资深架构师、微服务技术专家
171讲 171课时·约2000分钟10069
单独订阅¥299
2人成团¥199
19
本节摘要
登录 后留言

精选留言(28)

  • 小猴子
    老师你的下一代微服务安全架构中第二种模式用户带着JWT到网关不经过授权服务器再次验证完全就是有问题不安全的为啥还讲这种?为啥要省一步操作埋下这么大的隐患?这是企业级应用?

    作者回复: jwt是无状态自包含自验证,实现比较轻量,目前业界蛮流行的,很多应用采用jwt,因为大部分应用场景安全并不非常严格,另外jwt也可合理缩短有效期,或在网关上进一步定制加强安全验证。

    2018-12-28
    1
    2
  • shine
    OAuth是为访问第三方资源设计的,微服务架构下,访问的都是自身的资源,传统基于Token授权框架完全适用,整体实现比OAuth要简化不少,那么引入OAuth作为应用的授权框架的意义是什么?

    作者回复: oauth2是一个授权框架和规范,这个规范试图覆盖主要的微服务安全场景(第三方访问,无线应用,企业内部应用),目前在第三方访问和无线应用用得比较多,企业内部(包括内部微服务间调用)其实没有这么严格,各种不同做法(传统token,key,用户名/密码,ip黑白名单等)。

    2018-09-16
    2
  • 张顺青
    不能缓存下来看吗

    作者回复: 谢谢反馈🌹会反馈给极客时间

    2018-05-22
    2
  • shine
    网关的OAuth Filter和服务的OAuth Filter具体分别处理什么?请求资源服务接口时,权限访问控制的步骤应该是放在网关还是具体的服务上?感觉使用网关统一控制处理,能覆盖大部分场景,应该会有一些场景还是难以满足,比如一些数据级的权限。比如论坛删帖的场景,用户可以删除自己的帖子,版主可以删管理的版块下的帖子,系统管理员可以删所有帖子,如果要在网关统一处理,需要分成3个独立的服务接口,如果在服务自身处理,可以在一个接口内提供。

    作者回复: ppt中,网关上的OAuth Filter主要用于access token校验,获取jwt token;服务上的OAuth Filter,主要用于jwt的解释,获取用户和权限等信息,填充SecurityContext类似构件。用户权限在哪里做?既可以在网关上集中做,也可以在服务端自己做,都能做到,各有优劣,视企业和架构上下文选择即可。

    2018-09-16
    1
  • 学明
    哎,这个留言点半天才点开。
    请教问题,以前使用session来管理会话,同事控制5分钟无活跃请求失效,重新登录。如果使用token的方式,如何方便实现呢?

    作者回复: 传统单块web应用常用session式会话,现代微服务一般用基于令牌的分布式会话。令牌token有有效期,可在资源端(或通过网关集中)通过授权服务器集中校验,过期校验不通过。如果用jwt令牌,内含过期时间,资源端可自校验。

    2018-08-14
    1
  • chengUFO
    token过期怎么办?

    作者回复: token正常过期用户一般需重新登录获取新令牌,也可采用refreshtoken直接获取新令牌。

    2018-07-21
    1
  • frog3
    波波老师,能否讲下微服务内部调用的安全问题,如何解决呢?主要是两种,1,微服务内部相互调用,2,非微服务体系下既有存量系统也要调用微服务的某接口如何保证安全问题

    作者回复: 按oauth2标准做法,内部服务间调用可以采用客户凭证方式(client credentials)获取令牌并访问目标服务,服务端校验令牌。如果用简单做法,可以做白名单,在网关或服务器端过滤。还有一种常见办法,生产环境隔离。

    2018-05-20
    1
  • Song
    感谢波波老师的讲解,对OAuth2的理论以及企业里的一些场景应用有了一定的了解。

    作者回复: 加油!

    2019-06-23
  • rajon
    有spring cloud gateway网关集成oauth2的例子吗

    作者回复: Spring Cloud Gateway比较新,这个我还没有实现过,找了一些样例供你参考,你自己需要进一步调研和尝试:

    https://github.com/artemMartynenko/spring-cloud-gateway-oauth2-sso-sample-application

    https://github.com/spring-cloud-samples/sample-gateway-oauth2login

    https://github.com/spring-cloud/spring-cloud-gateway/issues/179#issuecomment-406238177

    2019-06-14
  • 大鹏
    谢谢老师回答,还有点疑惑:
    1.既然能控制client必须通过gateway去访问后台微服务,那么只要在gateway上进行一次token校验就可以了,后台服务为什么还要再进行一次自校验?如果后台服务不进行自校验,这样的安全缺陷是什么。
    2.为什么不直接颁发jwt,而是存储access token和jwt,并且在后面交换。是因为gateway上的校验access token就够了,access token更轻量吗?

    作者回复: 1,如果网关做了集中校验,后台服务再自校验并非必须,假设网关和后台服务在同一个信任域。但也有公司网关和后台服务可能并不一定完全信任,或者后台服务安全特别敏感(比如交易相关),需要严格再次校验。
    2, jwt有个问题是令牌里头编码的信息是可见的,有些场景下,不想让用户端看见jwt里头信息(比如用户名角色等),所以对外可以用透明令牌,对内可以再转成jwt。

    2019-06-10
  • 大鹏
    老师,有两个问题:
    1.客户有没有可能绕过网关,直接访问后台微服务。这样即使token被gateway在redis中掉销了,也能访问到后台数据。后台微服务jwt自检验对这种情况不起作用。
    2.为什么颁发的是access token ,经过gateway的时候再换成jwt token ,因为access token更轻量级吗?

    作者回复: 你好,1,如果采用网关统一认证,那么所有API请求必须经过网关,这个在物理部署架构上可以做到。2,access token换成jwt token,是因为传统访问令牌access token一般是无意义的随机字符串,一般不包含用户名/角色等用户信息(后台服务通常需要这些信息),转成jwt的话,里头可以包含这些信息。当然也可以不转jwt,直接把用户名等信息通过HTTP Header往后传递,更简单一点。

    2019-06-05
  • 萬物一馬
    波波老师,请教 同一个B服务提供的方法, 从网关-A服务-B服务 可以通过OAuth2 进行认证...但如果A服务-B服务,内部调用(诸如,定时任务)这样没有条件进行oauth2认证的...这2种情况怎么区分?

    作者回复: 内部调用(定时任务之类),可以采用OAuth2的客户端模式(client credentials),由机器直接发起,不需要人的参与。当然,对于内部调用,你也需要评估是否需要oauth2这种较严格安全授权机制,毕竟会引入很多复杂性。

    2019-03-21
  • 行知
    应用的access token 和用户的 access token 只是针对的对象不同,但使用oauth2.0的协议可以相同的。应用的access token 更多的使用client 这种flow。不知道,我的理解对吗?
    微信的二维码登录,生成的二维码的流程:1、更加授权码flow获取应用access token;2、根据access token生成时效性的ticket;3、在对这些信息进行加密(这其实就是jwt)生成对应的二维码;

    作者回复: 其实acces token没有应用的和用户的之分,它是授权服务器授予应用(正式叫客户应用)的凭证,通过这个凭证应用就可以代表用户去访问用户的资源,这个是官方定义。实际应用中,企业一般会基于oauth2协议做一些定制扩展,微信的做法我认为就是一种定制扩展。

    2019-03-07
  • james
    您好, 方案3其实就是授权服务器这个微服务将accessToken存储到了自己的MySQL, 并缓存到了自己的Redis的意思是把? Redis属于授权服务器的范畴, 而不属于网关范畴, 网关是通过http/rpc调用授权服务器的接口来实现这一步

    作者回复: 对,方案3主要就是增加redis缓存,提升令牌校验性能,因为网关集中校验令牌会比较频繁。

    2019-01-24
  • 西兹兹
    波波老师,请问,如果网关->A服务, A服务调用B服务;
    网关把JWT传给了A, 但是A调用了B服务的时候如何带JWT呢? 是否A->B也要经过网关呢?

    作者回复: 不用经网关,直要能通过http header往后传递即可,比如在spring中很容易做到,比如从request context里头获取jwt,通过http client再以http header方式往后传递。

    2018-12-13
  • 张振华
    如果一个比较大点的企业,想做一个统一的认证授权系统(假如说叫三统一系统),其他软件(多种形式的,单页的或者手机端的,也有微服务)的认证授权都对接这个三统一系统,请问老师,用OAuth2可以满足需求吗?是不是4中授权方式都需要进行实现?

    作者回复: oauth2就是针对无线/单页/第三方等场景访问微服务而设计的授权协议。如果自己实现,具体实现哪几种授权方式,可根据需求定。也可基于spring security oauth2等组件扩展,它内置已实现4种主要的oauth2授权方式。

    2018-10-21
  • 安静
    细细想来,自己之前的公司也是使用的第三种方案,以前在公司没有细细深入了解这块。波波老师案例写好后,文章地址贴出来我来参考下。

    作者回复: 恩,最后一个模块(第9模块),会有一个综合案例,会讲解oauth2服务器和zuul网关的集成,使用类似第三种方案,网关集中验令牌,验通过则将用户信息向后台服务传递

    2018-09-21
  • shine
    1.Refresh Token应该保存在用户客户端(用户的浏览器/App,对应OAuth中的User Agent)还是发起请求的服务器(对应OAuth中的Client):
    (1)如果保存在用户客户端,有泄露风险,安全性如何保证?
    (2)如果保存在服务器,用户客户端和服务器之间只用access token,服务器判断access token是否过期(jwt的场景)或者发送资源请求发现token过期,再拿Refresh Token去刷新,那么服务器需要长期保存access token和refresh token的对应关系,即使access token已过期,access token的保存时间需要与refresh token一致,直到获取新的access token为止才能清除,否则用户后续请求时就无法用过期的access token找到对应的refresh token,如果是上述场景,那么区分access token/refresh token事实上毫无意义,使用一个token就可以了

    2.JWT与OAuth结合的场景,如果仍需要对每次请求做中心化的验证,也就是1、3两种架构,那么JWT的意义是什么,感觉没有必要采用JWT,直接使用无意义随机字符串做Token就行了,前提是请求参数已做了签名,防止篡改

    对于上面两个问题,个人理解OAuth2引入Refresh Token的本意是缩短access token的时效,实现access token的“及时”回收,包含了一个隐藏条件就是认证服务器给client的access token一定是资源服务器可以识别和校验的,也就是JWT这类自包含业务信息、过期时间、不可伪造的Token,采用第2种架构才符合OAuth2的设计理念,当然因为没有中心化的验证,access token的回收其实并不“及时”,需要等到JWT设置的过期时间。如果业务要求access token能够实时撤销,那么应采用中心化的验证,这个时候没有必要用refresh token和JWT了。

    如果采用refresh token,对于微服务架构采用OAuth为自身应用提供授权框架的场景,refresh token存用户客户端,通过加密存储保障存储安全性,只在调用刷新接口时解密,并用HTTPS保障传输安全性,但客户端天然不能完全避免风险,如有必要可以通过2种方式强化:
    1.与设备指纹的绑定,调用刷新接口时在服务器端检测refresh token是否与颁发时的设备环境一致,是否已存在泄露隐患
    2.每次调用刷新接口,同时更换新的refresh token,如果用户端拿旧的refresh token再次调用刷新接口,提示用户存在泄露的可能

    对于调用第三方平台的场景,用户客户端并不需要与第三方的access token/refresh token直接打交道,所以access token/refresh token都应该保存在服务器上。

    作者回复: 你好,你的回复很长,应该对oauth2有自己的理解和思考,如需进一步交流,可以加我微信号bulldog2015(注明来自极客时间的客户)。我这边简单回复几点:1)refresh token一般只在授权码模式才有,OAuth Client Web服务器需要保存相关映射关系(比如可以存用户表中),主要目的是避免用户每次都要走一个完整的授权码模式流程去获取access token,这个很烦,refresh token可以简化这个流程,Web服务器后台用refresh token自动获取新的access token。2)在授权码模式中,access token/refresh token只在OAuth Client Web服务器上,一般不会流到用户浏览器User Agent上去,保证安全性,3)在通过网关集中校验token的场景中(方式一和三),有了access token后,jwt确实没有特别必要的,很多公司通过access token校验后,直接获取用户信息(比如userId),直接向后台服务传递,没有必要jwt,这个在视频中也有说明,如果使用jwt也可以,对内部服务调用会更规范和安全,当然成本更高一点。

    2018-09-17
  • siesteven
    想缓存,路上看。。。

    作者回复: 谢支持🌹加油💪

    2018-09-01
  • 宛珩
    access token 被他们截取后,如何保证其安全性?

    作者回复: access token如果是bearer的话,就像钱一样,别人偷走也可以用的,没有绝对的安全,一般传输层用https防截取,然后缩短token过期时间到安全可接受范围。

    2018-08-29
收起评论
看过的人还看
从0开始学架构

李运华  资深技术专家

59讲 | 39235 人已学习

¥99
Java核心技术面试精讲

杨晓峰  前Oracle首席工程师

43讲 | 43543 人已学习

拼团 ¥79 原价 ¥99
左耳听风

陈皓  网名“左耳朵耗子”,资深技术专家,骨灰级程序员

108讲 | 40807 人已学习

拼团 ¥199 原价 ¥299
微服务架构核心20讲

杨波  拍拍贷框架研发部总监,资深架构师,微服务技术专家

20讲 | 14084 人已学习

¥39