下载APP
登录
关闭
讲堂
算法训练营
Python 进阶训练营
企业服务
极客商城
客户端下载
兑换中心
渠道合作
推荐作者
当前播放: 167 | Demo展示(lab05)(上)
00:00 / 00:00
标清
  • 标清
1.0x
  • 2.0x
  • 1.5x
  • 1.25x
  • 1.0x
  • 0.5x
网页全屏
全屏
00:00
付费课程,可试看

微服务架构实战160讲

共171讲 · 171课时·约2000分钟
9941
免费
01 | 第一模块课程介绍
免费
02 | 微服务安全要解决什么问题
免费
03 | 白话 OAuth2
免费
04 | OAuth2 的正式定义
免费
05 | OAuth2 有哪些典型模式
06 | OAuth2 模式该如何选型
07 | Spring Security OAuth...
08 |【实验】授权码模式授权服务...
09 |【实验】简化模式授权服务器
10 |【实验】密码模式授权服务器
11 |【实验】客户端模式授权服务...
12 | 实验一扩展环节
13 |【实验】Web 应用接入授权...
14 | 实验二扩展环节
15 | 什么是 JWT 令牌
16 |【实验】授权服务器支持 JW...
17 | 实验三扩展环节
18 |【实验】Android 无线应用...
19 |【实验】AngularJS 单页应...
20 |【实验】GitHub社交登录实验...
21 | 【实验】OAuth2安全风险CS...
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实操...
41 | Apollo Client和Spring集...
42 | Apollo Client和Spring集...
43 | Apollo Client和Spring ...
44 | Apollo开放平台接入实操...
45 | Spring Cloud Config简...
46 | Apollo vs Spring Clou...
47 | Apollo FAQ和开发常见问...
48 | 参考资源和后续课程预览
免费
49 | 第三模块课程介绍
免费
50 | Zuul网关和基本应用场景
免费
51 | Zuul网关高级应用场景
52 | Zuul网关架构剖析
53 | Zuul网关代码剖析(Code ...
54 | Zuul网关过滤器管理工具(...
55 | 前置过滤器实验(Lab01)
56 | 路由过滤器实验(Lab02)
57 | 后置过滤器实验(Lab03)
58 | Zuul网关对接Apollo(Lab0...
59 | Zuul网关生产部署实践
60 | Zuul网关路由管理实践
61 | 基于网关的两层路由体系
62 | Spring Cloud Zuul(Lab...
63 | Zuul2.0简介
64 | Zuul网关生产最佳实践
65 | 参考资源和后续课程预览
免费
66 | 第四模块课程介绍
免费
67 | 调用链监控业务需求
免费
68 | 调用链监控原理
69 | 调用链监控产品和比较
70 | 点评 CAT 背景介绍
71 | CAT 典型报表
72 | CAT 告警简介
73 | CAT 架构设计
74 |【实验】CAT 本地部署
75 | CAT 埋点案例和代码剖析...
76 |【实验】CAT 埋点案例
77 | Zuul 网关集成 CAT 代...
78 |【实验】Zuul 网关集成 CA...
79 | CAT 生产埋点实践
80 | CAT 生产部署实践
81 | CAT 生产治理实践
82 | Spring Cloud Sleuth ...
83 |【实验】Spring Cloud Sle...
84 | 参考资源和后续课程预览
免费
85 | 第五模块课程介绍
免费
86 | 容错限流需求
免费
87 | 容错限流原理
88 | Netflix Hystrix 背景...
89 | Hystrix 设计原理
90 | Hystrix 主要概念
91 | 信号量 vs 线程池隔离
92 | Hystrix 主要配置项
93 |【实验】Hystrix 基础实验
94 | Hystrix 模拟案例分析 ...
95 |【实验】Hystrix + Dash...
96 |【实验】Hystrix + Dash...
97 | 网关集成 Hystrix (Co...
98 |【实验】Spring Cloud Hy...
99 | Netflix Turbine 简介
100 | Hystrix 生产最佳实践
101 | 参考资源和后续课程预览
102 | 第六模块课程介绍
103 | 服务发现需求和模式(上...
104 | 服务发现需求和模式(下...
105 | Netflix Eureka 和 Ri...
106 | Eureka 和 Ribbon 架...
107 |【实验】Spring Cloud Eu...
108 |【实验】Spring Cloud Eu...
109 | Spring Cloud Eureka ...
110 | Eureka进阶:自保护模式
111 | Eureka进阶:健康检查和...
112 |【实验】Spring Cloud Zu...
113 |【实验】Spring Cloud Zu...
114 | 常用服务发现组件比较
115 | ServiceMesh 和 Istio...
116 | 基于 Eureka、Zuul 和...
117 | 参考资源和后续课程预览
118 | 第七模块课程介绍
119 | 监控模式分类
120 | BusDevOps 和测量驱动开...
121 | Prometheus 简介
122 | Prometheus 架构设计
123 | Prometheus 基本概念
124 |【实验】Prometheus 起步...
125 |【实验】Prometheus起步查...
126 |【实验】Prometheus起步查...
127 |【实验】Prometheus + G...
128 |【实验】Prometheus + G...
129 |【实验】Prometheus + A...
130 |【实验】Prometheus + A...
131 |【实验】Java 应用埋点和...
132 |【实验】NodeExporter 系...
133 |【实验】Spring Boot Act...
134 | Prometheus 监控最佳实...
135 | 主流开源时序数据库比较
136 | 开源分布式监控平台 ZMo...
137 | 微服务监控体系总结
138 | 参考资源和后续课程预览
139 | 课程概述和背景
140 | 架构和设计
141 | 开发环境搭建
142 | 基础代码(code review...
143 | 数据访问模块(code rev...
144 | OAuth2服务模块(code r...
145 | Web服务模块(code revi...
146 | 启动流程(code review...
147 | 起步准备实验(lab02)
148 | OAuth2授权码模式实验(l...
149 | OAuth2简化模式实验(lab...
150 | OAuth2用户名密码模式实...
151 | OAuth2客户端模式实验(l...
152 | OAuth2令牌校验实验(lab...
153 | OAuth2令牌刷新实验(lab...
154 | 项目复盘和扩展环节
155 | 参考资源和后续课程预览
156 | 课程概述和背景
157 | 需求和架构设计
158 | 开发环境搭建(lab01)(...
159 | 开发环境搭建(lab01)(...
160 | 项目业务代码(Code Rev...
161 | Apollo配置中心集成(lab...
162 | Zuul-Eureka-Ribbon-H...
163 | Gravitee OAuth2集成(l...
164 | Zuul网关集中令牌校验(C...
165 | CAT调用链集成(lab04)...
166 | CAT调用链集成(lab04)...
167 | Demo展示(lab05)(上)
168 | Demo展示(lab05)(下)
169 | Prometheus监控集成(Cod...
170 | 生产扩展环节
171 | 课程复盘总结
本节摘要

精选留言(2)

  • 波波老师,像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。

    1
  • 首先谢谢波波老师的回复,推荐的文章及项目对我很有帮助。其实我和同事也讨论在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。