西2020-07-25全程使用oauth2令牌，那么网关之后的每个微服务都需要自己根据令牌token去idp或者redis或者mysql中去查询用户信息，如果全程使用jwt令牌，主要是还是由于jwt自包含用户信息，存在暴露用户信息的安全风险。（如果jwt中只存在用户名，不存在其他相关信息也可以考虑全程使用jwt令牌）作者回复: 不错⛽️
21
良胜2020-08-22王老师，现在我正在搭建一个微服务框架，计划在网关层做集中认证，那网关是否应该时作为OAUTH2的client组建？ 另外你画的微服务的架构图，IDP 是作为什么角色？授权服务器还是client，另外Login Svc 又是承担什么工作？ 我目前遇到困难，我们期望不管是web侧还是app侧，统一使用token进行认证，并且登录使用手机号+验证码的方式，现在如果访问受限资源，默认会跳到login页面，不是返回json数据，请老师指点作者回复: 回复你的一些问题： 1. IDP就是基于OAuth2的授权服务，比方说可以采用Spring Security OAuth2来实现IDP。IDP可以自己实现登录认证的逻辑，也可以把登录认证的逻辑委派给其它服务，比方说独立的Login Service来实现。Spring Security OAuth2的登录认证逻辑就是可以plugin的，可以委派给其它服务来实现。 2. 网关和IDP没有直接的client关系，只是IDP需要支持一些API端点，网关可以通过这些端点来实现：1)令牌校验，2)获取对应的JWT令牌。 3. 登录使用手机号+验证代码，这是一种具体的基于双因素的认证方式，其实OAuth2本身只是要求用户在授权获取令牌前先进行登录认证，具体登录认证的方式它并不关心。Spring Security OAuth2的登录认证方式也是可以plugin的，你可以用默认的用户名密码方式，也可以定制为手机号+验证码方式。实际上Spring Security OAuth2就是基于Spring Security开发的，你只需要定制Spring Security来实现基于手机号+验证码的登录认证方式就可以。
共 2 条评论8
kylexy_08172020-08-02其实全程使用JWT，也没啥问题，只是如果想其较为安全，就要把公钥放在客户端，让其加密后再传输（或者获取到令牌后就直接加密存放在cookies或localstorage），但JWT的内容较多，即使加密后的内容也会较长，公网环境传输效率不高。而访问令牌，就是为了解决公网传输效率问题。不知有没理解对。作者回复: JWT是自包含令牌，里头可以包含一部分用户信息，全程使用JWT也可以，JWT内部的数据本身只是加签防篡改，本来就是客户端可见的，一般服务器端启用HTTPS就可以了，再做一次加密意义并不大。 相比JWT，普通访问令牌机制还有一个好处，就是可以集中吊销令牌，而JWT一般需要等到自然过期，因为它是自校验的。
共 2 条评论8
永旭2020-11-18老师你好, 查了下BFF相关文章 有些架构图里把BFF放在API 网关层左边, 挨着web层.也有放在API 网关层里边的 能分析分析这两种的有什么优势和劣势 , 区别吗 ?作者回复: BFF虽然是前端开发，但是它也是一种聚合API，所以它理应放在API网关后面，这样就可以统一通过网关实现反向路由，限流熔断，日志监控等功能。 所以BFF一般不放在API网关层前面，静态资源一般放在API网关层前面。 也有一些企业的做法是BFF聚合逻辑直接写在网关上的，这种在企业规模不大、BFF逻辑不复杂时也可以采用，可以节省硬件资源。
3- 永旭2020-11-06老师, 以前我接触的架构图里有DMG层, 会部署前端. 现在课程中 微服务架构图里已经没有了 DMG层了. 要是有的话能部署什么呢 ?
作者回复: 你说的应该是DMZ非军事区网络吧，在传统数据中心，在外网和内部受信网络之间一般有一个DMZ网络，这里头部署防火墙/反向代理/网关等可以增加各种安全防范措施。参考： https://en.wikipedia.org/wiki/DMZ_(computing) DMZ可以是物理的，也可以是逻辑的，在上文的架构图中，防火墙+Ingress+Gateway也可以算是在DMZ区内，可以增加各种安全措施。
3 
inrtyx2020-07-25第六点是关于 Web Session，这个不太明白。token信息肯定要放浏览器啊！不然岂不是每次请求都要登录？作者回复: 网站会话有几种做法，一种是Session数据都存在服务器端，客户端浏览器cookie中只存sesssionID，我把这种称为Web Session，这种是服务器端有状态的Session技术。另外一种是Session数据都存在浏览器cookie中，我把这种称为客户端Session，这种是服务器端无状态的Session技术。
共 3 条评论3
往事随风，顺其自然2020-07-25全程采用JWt，用户信息容易暴露，对于安全级别高，最好不使用，对于oauth在安全级别更高，但是实现用户信息更复杂，混合之后，权衡了安全性和易用性，个人理解作者回复: 不错
共 2 条评论3
Geek_7c49532020-11-27有一个问题没有理解，APP用password模式登陆和APP上的浏览器打开统一认证页用用户名密码登录，这两者之间在安全层面上有什么区别？作者回复: APP用用户名密码模式，通过native界面登录，这是一个一步流程，并且APP上要存clientId+secret，黑客可以破解app获取clientId+secret，然后通过猜测轮训你的post登录接口偷取用户密码。 APP上的浏览器方式走的是一个3-legged完全OAuth2授权码流程，比较安全，很难被黑客利用，而且浏览器方式容易增加验证码和双因素等更安全校验机制。 请参考下文的第7点：Security Consideration https://www.kaper.com/cloud/micro-services-architecture-with-oauth2-and-jwt-part-3-idp/
2
Giggle2020-10-15请问老师，若只是一个移动端app，想让其实现Oauth协议，提供对其他app的授权登录，这种app的后台Oauth协议的实现是不是不适合使用SpringSecurityOauth这个框架，因为我看框架源码里面授权码模式或者简易模式都是基于浏览器重定向机制实现返回授权码code或者token，用户未授权情况下还会返回相应的授权页面，我是不是可以理解SpringSecurityOauth其实是解决网站和网站的第三方授权的场景，假如我是一个移动端的后台，就不适合使用这个框架。作者回复: 移动端原生App也可以采用OAuth2的授权码模式(建议采用支持PKCE的增强型授权码模式)，这时候可以在App中以嵌入方式启动手机浏览器，走授权码申请流程，等IDP 返回授权码到 App 浏览器之后，App 可以截取浏览器带回的授权码，然后App可以继续走后面令牌获取的流程。 所以这个流程App需要借助手机上的浏览器这个中介，来走完OAuth2的授权码流程，这个是目前针对原生App采用OAuth2协议的推荐做法。 具体参考本文的[场景 2：第一方移动应用 + 授权码许可模式]的描述。 额外参考： https://auth0.com/blog/oauth-2-best-practices-for-native-apps/ https://auth0.com/docs/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce
2
Tim Zhang2020-07-27网关获得 JWT 令牌，校验 Scope 是否有权限调用 API，如果有就转发到后台 API 进行调用。 校验是如何校验的？ 并且scope 和 authority有啥区别么作者回复: 企业根据具体场景，需要定义一个scope和API之间的权限关系表，这个表需要单独维护，并且可以缓存在网关上，加快网关的校验。所谓校验，就去查这张表，看某个scope能否访问某个API。 scope和authority并没有所谓官方定义，你可以根据上下文赋予它们具体的语义。
共 2 条评论2