精选留言(3)

• 
  DDs moving castle

  2019-11-13

  多谢波波老师的讲解和推荐，fusionauth针对不同应用场景的登录认证流程我看了，真的很细致了，话说您是怎么找到了，我之前也看过fusionauth，但只找到了类似API文档的部分，厉害。
  
  我说的除了在Auth Service维护集中状态，还维护每个应用的登录状态，其实是从原来公司在单体应用时引入的开源CAS单点登录的思路来的，fusionauth的文章中和这篇的思路是一样的。
  标题：(RECOMMENDED) OAuth 2 authorization code grant using sessions
  https://fusionauth.io/articles/logins/spa/oauth-authorization-code-grant-sessions
  但这种方式的弊端是，SPA在登录时需要跳转到Auth Service的登录页面，由于公司的SPA登录页风格要统一，而且单页应用跳来跳去感觉体验不是很好，虽然硬着头皮做了，但想优化一下。
  不知道上面链接这种方式，波波老师什么看法？？
  
  另外，我在看fusionauth的登录流程中发现，他们推荐一种将OAuth2的JWT格式的accessToken、引用类型的refreshToken放在cookie中返回给客户浏览器的做法，之后将JWT格式的accessToken当做登录凭证的做法，这种做法确实可以实现，从中可以获取到user信息，但我对于是否应该将OAuth的accessToken用于认证持否定态度，或者说最好不要。我从之前找到的一篇ORY的FAQ中看到了和我类似的观点：
  https://www.ory.sh/docs/next/hydra/faq#should-i-use-oauth2-tokens-for-authentication
  网上也有人使用accessToken认证的凭证，也有单独颁发认证凭证再在服务器端与accessToken关联的。请问波波老师对于使用OAuth的accessToken做登录认证是什么看法？？

  展开

  作者回复: 第一个问题，我的建议是遵循业界规范或最佳实践流程，因为这些流程已经经过行业安全专家论证，也经过工业界踩坑才总结沉淀下来，你没必要重造轮子，如果你绕开，虽然能省事，但是难免留下风险漏洞。
  
  第二个问题，OAuth2只是一种代理授权(delegated authorization)协议，严格不是身份认证协议，fusionauth的推荐的做法，已经不是纯OAuth2协议，而是一种基于JWT的OIDC(openid connect)协议的变体，OIDC是在OAuth2的基础上增加身份认证层。官方的OIDC也不推荐access token同时用作身份认证，而是有单独的identity token(常用JWT)。fusionauth推荐的做法，可以认为是OIDC的一种变体，对于第一方应用(都是一个企业自己开发的应用)，应该是可行的，如果涉及第三方，则需要考虑严格的OIDC协议。
  
  关于OAuth2和OIDC协议，建议读一下OAuth2 in Action这本书，对协议流程细节，背后原理有详细解释。http://product.dangdang.com/27851751.html
  
  

  

  
• 
  DDs moving castle

  2019-11-11

  波波老师，我们公司是做金融相关系统的，还是想考虑有状态的认证架构，而且不想只在Auth Service认证服务这里维护一个集中状态，因为这样如果Auth Service不可用，整个系统无论登录和校验登录状态都做不了了，会导致整个系统不可用，所以除了Auth Service认证服务维护登录状态，在通过Auth Service单点登录后的应用系统微服务也想维护个登录状态，感觉这样只会在单点登录时和Auth Service有交互，其它校验登录状态时在自己应用内部查找登录状态即可，请问如果在微服务架构中要实现这样的有状态架构，有什么项目或者案例可以参考吗？？
  
  另外Auth Service考虑使用OAuth2实现，对于第一方应用想使用password模式，但感觉实现SSO有点麻烦，因为浏览器不会直接与OAuth2服务交互，无法种下OAuth2服务的cookie；
  对于第三方想使用授权码模式，但现在前后端分离的架构下，前端要实现授权码模式的多次重定向且登录页面与应用系统风格统一又比较难；
  请教波波老师有什么建议或者资料案例、架构设计推荐吗？？
  多谢。

  展开

  作者回复: 我目前经历的两家公司，一家是旅游网携程，另外一家是拍拍贷金融，这两家都是基于令牌的集中状态式认证，集中状态好处是严格安全而且可以集中吊销。一般到这个体量的公司，Auth Service的高可用是必须要做到的。
  
  除了集中状态认证，目前业界比较流行的就是基于JWT的无状态认证(这个其实也有状态，只是状态被编码在JWT令牌里头)。你讲的既可以集中服务器认证，也可以在集中服务器不可用时，进行本地local认证方式，我暂时还没有经验。
  
  针对不同应用场景(传统Web/单页SPA/无线)的登录认证流程，这里有一个最全面的链接，里头的流程图很细致，供参考研究：
  https://fusionauth.io/articles/logins/types-of-logins-authentication-workflows
  
  
  

  

  
• 
  海罗沃德

  2019-09-19

  用户如果登陆后操作了一段时间，JWT过期了但是用户并没有结束使用，要如何实现不需要重新登陆就能更新JWT令牌？

  作者回复: 可以简单搞个算法，如果JWT临近过期(比如过期前10分钟）客户还有不断操作，可以自动刷新令牌，自动延长一个周期。

  

  