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

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

场景

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

问题一

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

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

小B：你指定 scope 就可以了

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

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

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

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

问题二

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

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

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

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

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

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

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

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

问题三

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

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

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

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

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

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

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

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

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

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

群主大帅哥：完全没问题！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 的 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 产品技术白皮书》