- 标清
- 2.0x
- 1.5x
- 1.25x
- 1.0x
- 0.5x
微服务架构实战160讲
精选留言(28)
2018-12-28老师你的下一代微服务安全架构中第二种模式用户带着JWT到网关不经过授权服务器再次验证完全就是有问题不安全的为啥还讲这种？为啥要省一步操作埋下这么大的隐患？这是企业级应用？作者回复: jwt是无状态自包含自验证，实现比较轻量，目前业界蛮流行的，很多应用采用jwt，因为大部分应用场景安全并不非常严格，另外jwt也可合理缩短有效期，或在网关上进一步定制加强安全验证。
1 2
2018-09-16OAuth是为访问第三方资源设计的，微服务架构下，访问的都是自身的资源，传统基于Token授权框架完全适用，整体实现比OAuth要简化不少，那么引入OAuth作为应用的授权框架的意义是什么？作者回复: oauth2是一个授权框架和规范，这个规范试图覆盖主要的微服务安全场景（第三方访问，无线应用，企业内部应用），目前在第三方访问和无线应用用得比较多，企业内部（包括内部微服务间调用）其实没有这么严格，各种不同做法（传统token，key，用户名/密码，ip黑白名单等）。
2
2018-05-22不能缓存下来看吗作者回复: 谢谢反馈🌹会反馈给极客时间
2- 2018-09-16网关的OAuth Filter和服务的OAuth Filter具体分别处理什么？请求资源服务接口时，权限访问控制的步骤应该是放在网关还是具体的服务上？感觉使用网关统一控制处理，能覆盖大部分场景，应该会有一些场景还是难以满足，比如一些数据级的权限。比如论坛删帖的场景，用户可以删除自己的帖子，版主可以删管理的版块下的帖子，系统管理员可以删所有帖子，如果要在网关统一处理，需要分成3个独立的服务接口，如果在服务自身处理，可以在一个接口内提供。
作者回复: ppt中，网关上的OAuth Filter主要用于access token校验，获取jwt token；服务上的OAuth Filter，主要用于jwt的解释，获取用户和权限等信息，填充SecurityContext类似构件。用户权限在哪里做？既可以在网关上集中做，也可以在服务端自己做，都能做到，各有优劣，视企业和架构上下文选择即可。
1 
2018-08-14哎，这个留言点半天才点开。
请教问题，以前使用session来管理会话，同事控制5分钟无活跃请求失效，重新登录。如果使用token的方式，如何方便实现呢？作者回复: 传统单块web应用常用session式会话，现代微服务一般用基于令牌的分布式会话。令牌token有有效期，可在资源端（或通过网关集中）通过授权服务器集中校验，过期校验不通过。如果用jwt令牌，内含过期时间，资源端可自校验。
1
2018-07-21token过期怎么办？作者回复: token正常过期用户一般需重新登录获取新令牌，也可采用refreshtoken直接获取新令牌。
1
2018-05-20波波老师，能否讲下微服务内部调用的安全问题，如何解决呢?主要是两种，1，微服务内部相互调用，2,非微服务体系下既有存量系统也要调用微服务的某接口如何保证安全问题作者回复: 按oauth2标准做法，内部服务间调用可以采用客户凭证方式（client credentials）获取令牌并访问目标服务，服务端校验令牌。如果用简单做法，可以做白名单，在网关或服务器端过滤。还有一种常见办法，生产环境隔离。
1
2019-06-23感谢波波老师的讲解，对OAuth2的理论以及企业里的一些场景应用有了一定的了解。作者回复: 加油！
2019-06-14有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-10谢谢老师回答，还有点疑惑：
1.既然能控制client必须通过gateway去访问后台微服务，那么只要在gateway上进行一次token校验就可以了，后台服务为什么还要再进行一次自校验？如果后台服务不进行自校验，这样的安全缺陷是什么。
2.为什么不直接颁发jwt，而是存储access token和jwt，并且在后面交换。是因为gateway上的校验access token就够了，access token更轻量吗？作者回复: 1，如果网关做了集中校验，后台服务再自校验并非必须，假设网关和后台服务在同一个信任域。但也有公司网关和后台服务可能并不一定完全信任，或者后台服务安全特别敏感(比如交易相关)，需要严格再次校验。
2， jwt有个问题是令牌里头编码的信息是可见的，有些场景下，不想让用户端看见jwt里头信息（比如用户名角色等），所以对外可以用透明令牌，对内可以再转成jwt。- 2019-06-05老师，有两个问题:
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-03-21波波老师,请教 同一个B服务提供的方法, 从网关-A服务-B服务 可以通过OAuth2 进行认证...但如果A服务-B服务,内部调用(诸如,定时任务)这样没有条件进行oauth2认证的...这2种情况怎么区分?作者回复: 内部调用(定时任务之类)，可以采用OAuth2的客户端模式（client credentials），由机器直接发起，不需要人的参与。当然，对于内部调用，你也需要评估是否需要oauth2这种较严格安全授权机制，毕竟会引入很多复杂性。
2019-03-07应用的access token 和用户的 access token 只是针对的对象不同，但使用oauth2.0的协议可以相同的。应用的access token 更多的使用client 这种flow。不知道，我的理解对吗？
微信的二维码登录，生成的二维码的流程:1、更加授权码flow获取应用access token；2、根据access token生成时效性的ticket；3、在对这些信息进行加密(这其实就是jwt）生成对应的二维码；作者回复: 其实acces token没有应用的和用户的之分，它是授权服务器授予应用(正式叫客户应用)的凭证，通过这个凭证应用就可以代表用户去访问用户的资源，这个是官方定义。实际应用中，企业一般会基于oauth2协议做一些定制扩展，微信的做法我认为就是一种定制扩展。
2019-01-24您好, 方案3其实就是授权服务器这个微服务将accessToken存储到了自己的MySQL, 并缓存到了自己的Redis的意思是把? Redis属于授权服务器的范畴, 而不属于网关范畴, 网关是通过http/rpc调用授权服务器的接口来实现这一步作者回复: 对，方案3主要就是增加redis缓存，提升令牌校验性能，因为网关集中校验令牌会比较频繁。
2018-12-13波波老师，请问，如果网关->A服务, A服务调用B服务；
网关把JWT传给了A， 但是A调用了B服务的时候如何带JWT呢？ 是否A->B也要经过网关呢？作者回复: 不用经网关，直要能通过http header往后传递即可，比如在spring中很容易做到，比如从request context里头获取jwt，通过http client再以http header方式往后传递。
2018-10-21如果一个比较大点的企业，想做一个统一的认证授权系统（假如说叫三统一系统），其他软件（多种形式的，单页的或者手机端的，也有微服务）的认证授权都对接这个三统一系统，请问老师，用OAuth2可以满足需求吗？是不是4中授权方式都需要进行实现？作者回复: oauth2就是针对无线/单页/第三方等场景访问微服务而设计的授权协议。如果自己实现，具体实现哪几种授权方式，可根据需求定。也可基于spring security oauth2等组件扩展，它内置已实现4种主要的oauth2授权方式。
2018-09-21细细想来，自己之前的公司也是使用的第三种方案，以前在公司没有细细深入了解这块。波波老师案例写好后，文章地址贴出来我来参考下。作者回复: 恩，最后一个模块（第9模块），会有一个综合案例，会讲解oauth2服务器和zuul网关的集成，使用类似第三种方案，网关集中验令牌，验通过则将用户信息向后台服务传递
- 2018-09-171.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-01想缓存，路上看。。。作者回复: 谢支持🌹加油💪
2018-08-29access token 被他们截取后，如何保证其安全性？作者回复: access token如果是bearer的话，就像钱一样，别人偷走也可以用的，没有绝对的安全，一般传输层用https防截取，然后缩短token过期时间到安全可接受范围。