JustAuth 用户故事：群主，你的代码出 BUG 了！

以下内容改编整理自 JustAuth 社区群（QQ 群，230017570），为保护隐私，已经隐去相关关键信息，文章部分内容为润色后的。

场景

小帅哥 在使用 JustAuth 时遇到了一些问题，通过在JustAuth 社区群（QQ 群）中提问的形式寻找解决方案。期间分别由小A、小B等群友参与解答，最后在群主大帅哥的细致解答下，成功解决了小帅哥的所有疑问，并获得小帅哥的全方位好评！

问题一

小帅哥：群主大帅哥，我用 Gitee 测试时，遇到了一个 BUG，浏览器提示我“存在错误，请求范围无效、未知或格式不正确”，这是因为什么？是你写出 BUG 了吗？

小A：你这是参数错误，不关 JustAuth 的问题吧。“狗头笑”

小B：你指定 scope 就可以了

群主大帅哥：经老夫掐指一算，你这就是小B 说的问题，在使用 JustAuth 的自定义 scope 功能^[1]时，不建议使用所有 scope，因为部分平台的 scope 权限需要特殊申请。你可以将自定义 scope 的配置去掉，这样的话 JustAuth 会使用该平台默认的 scope 进行授权。

小帅哥：哇，真的是耶！问题已经解决了，群主真好用！

群主大帅哥：咳咳，注意用语，是 JustAuth 真好用，群主是人，不能随便用。(^_^)

小帅哥：群主牛逼！真棒！

问题二

小帅哥：群主大帅哥，前后端分离的项目中，在登录时，在 callback 里面, 是使用 response.sendRedirect 重定向到前端登录中间页吗?

小C：都分离了，为什么还要后端重定向，和后端没关了啊，后端返回token不就可以了吗？

群主大帅哥：这个问题非常好，解决方案可不少。你说已把文档找，问题还是搞不了。我猜你是没找对，要不不能这么累。进到这儿^[2]看一看，绝对能把问题办！

小帅哥：群主群主你真棒，三言两语就敢上。这个问题弄不了，正常流程怎么搞？

小A小B小C：你俩能不能正常点？

群主大帅哥：咳咳，言归正传，书接上文。前后端分离的项目正常流程是这样的：

1.第三方应用的回调地址填前端项目的可访问地址2.后台接口使用 JustAuth 的 request.authorize(xx) 生成授权链接，然后返回给前台3.前台获得授权链接后进行跳转4.第三方登录完成后回调到前端项目的可访问地址5.前端获取回调中的 code 和 state 等参数，传回后台，请求 token 和 userinfo

小帅哥：群主牛逼！我彻底明白了，你说的流程简单易懂。真棒！

问题三

小帅哥：群主大帅哥，state 用默认存储和 redis 存储有何区别啊？我看了名词解解^[3] 和高级特性里面的内容（使用 state^[4]和自定义 state 缓存^[5]），state 我看默认有效时间 3 分钟, 请问这个时间对哪里有影响呢?

群主大帅哥：state的有效期对【单次授权流程长时间没操作这个场景】有影响。一般来说用户进行授权登录都是实时的（即从用户点击授权登录、跳转到第三方登录授权、回调到业务系统这个流程是依次顺利操作的），很少遇到用户在授权时，跳转到第三方登录页面后，用户长时间没操作，等过了3分钟后再进行登录操作。这个时候 justauth 中的 state 已经过期了，用户在第三方登录成功回调到业务系统后，会授权失败。会提示state无效。这个时候就需要用户重新登录授权

小帅哥：明白了, 就是控制用户第三方登录的有效时间。

群主大帅哥：可以这么理解。state 是一次使用的，不可能让它长期滞留缓存。不过这个过期时间你可以根据你们自己的需要进行调整。你如果觉得这个时间短，那你可以调长一点，比如10分钟过期。

小帅哥：state 只要是随机数就行是吧？

群主大帅哥：对，随机数。

（大帅哥正在码字的时候）

小帅哥：bind:uuid 这样可以吗，因为想回调时好区分是绑定还是登录。

群主大帅哥：很棒，你已经会抢答了！确实可以这么操作，即在用户进行绑定的时候可以使用用户 id。

小帅哥：是 justauth 太棒了！接下来有时间想研究下大佬的升级作品 JAP^[6]。

群主大帅哥：完全没问题！JAP 是一款开源的登录认证中间件，基于模块化设计，为所有需要登录认证的 WEB 应用提供一套标准的技术解决方案，开发者可以基于 JAP 适配绝大多数的 WEB 系统（自有系统、联邦协议）。Just auth into any app!

小帅哥：哇！这么棒！那 JAP 有什么功能和优势？

群主大帅哥：好问题！本文最后我会给你详细解释。

群主大帅哥：前面提到可以用 UID 充当 state ，不过不建议直接使用 UID，最好用 id+随机数加密（要求可解密）后进行传输。state 是保证流程安全的，它就是为了防止 csrf 攻击的，如果你直接用用户id，也是可能存在被攻击的情况。比如这个回调请求被拦截后把state 替换成了攻击者的id，这个时候就会出问题。

小帅哥：行，我用md5 加密下。

群主大帅哥：额....，你md5加密后咋解密？不解密你咋知道是哪个用户的id？或者你还是用随机数，你本地把用户id和随机数关联起来就行。

小帅哥：了解了, 为安全起见，用对称加密 (AES) 对用户id 加密，回调时解密该id。同时校验该 id 合法性(是否存在)，绑定当前用户信息。

群主大帅哥：你真棒！

小帅哥：群主牛逼！真棒！

关于 JAP

JAP 是什么？

JAP 是一款开源的登录认证中间件，基于模块化设计，为所有需要登录认证的 WEB 应用提供一套标准的技术解决方案，开发者可以基于 JAP 适配绝大多数的 WEB 系统（自有系统、联邦协议）。

JAP 有哪些功能？

JAP 开源的统一登录认证标准组件 - 包含的功能

JAP 有什么优势？

•易用性：JAP 的 API 沿袭 JustAuth 的简单性，做到了开箱即用的程度。JAP 高度抽象各种登录场景，提供了多套简单使用的 API，极大程度的降低了开发者的学习成本和使用成本•全面性：JAP 全量适配 JustAuth 支持的第三方平台，实现第三方登录。同时也支持所有基于标准OAuth2.0 协议或者 OIDC 协议或者 SAML 协议的应用、系统，同时 JAP 还提供不同语言版本的项目 SDK，适配多种研发场景•模块化：JAP 基于模块化设计开发，针对每一种登录场景，比如账号密码、OAuth、OIDC等，都单独提供了独有的模块化解决方案•标准化：JAP 和业务完全解耦，将登录认证相关的逻辑抽象出一套标准的技术解决方案，针对每一种业务场景，比如用户登录、验证密码、创建并绑定第三方系统的账号等，都提供了一套标准的策略或者接口，开发者可以基于 JAP，灵活并方便的完成相关业务逻辑的开发和适配•通用性：JAP 不仅可以用到第三方登录、OAuth授权、OIDC认证等业务场景，还能适配开发者现有的业务系统的普通账号密码的登录场景，基本将所有登录相关的业务场景都已经涵盖。针对 WEB 应用，JAP 将提供满足各种不同登录场景的解决方案（和开发语言无关）

JAP 适用于哪些场景？

JAP 适用于所有需要登录认证功能的场景。比如：•要求规范：新项目立项，你们需要研发一套包含登录、认证的系统，并且从长远方面考虑，你们需要一套标准的、灵活的、功能全面的登录认证功能。•需求灵活：现有登录模块为自研，但是新一轮的技术规划中，你们想将登录认证模块重构，以更加灵活的架构适应后面的新需求，比如：集成 MFA 登录、集成 OAuth 登录、SAML登录等。•力求省事：你们的项目太多（或者是开发语言较多，比如：Java、Python、Node 等），每个项目都需要登录认证模块，想解决这种重复劳动的问题，使研发人员有更多的时间和精力投入到业务开发中，提高研发产能和研发效率。关于 JAP 的更多内容，可以参考《JAP 产品技术白皮书^[7]》

JustAuth 故事会：群主，你的代码出 BUG 了！