作者回复: 第一个问题，我的建议是遵循业界规范或最佳实践流程，因为这些流程已经经过行业安全专家论证，也经过工业界踩坑才总结沉淀下来，你没必要重造轮子，如果你绕开，虽然能省事，但是难免留下风险漏洞。 第二个问题，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

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

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

作者回复: token可以是无意义随机字符串，比如uuid，你在数据库里头只要建立用户名和token的映射关系就可以，后续可以通过用户找到token，或者通过token找到用户名，这样就可以了。

作者回复: www服务完全可以做成前后分离，之所以没有做，是因为这个项目是原版Staffjoy(也就是golang版)的一个简化克隆版，保留了原版的设计。 后面我会开发一个完全前后分离的电商应用，欢迎关注。