【开源】我和 JAP（JA Plus） 的故事

JA Plus 故事

程序员的故事如此简单之绕不过去的开源情结

我们准备做一件伟大的事，也可以说是一件真真正正普惠的事。

絮

是的，你没有看错，就是“絮”而非“序”，请允许我絮叨二三。

我们即将要做的，我们认为是一件伟大的事，也可以说是一件真真正正普惠的事。我们要开发一款真真正正国产的并且未来将会走向国际的完全开源的产品 - Just Auth Plus（以下简称 “JAP”）。

JAP 是 [JustAuth] gitee.com/yadong.zhang/JustAuth（以下简称 “JA”） 的升级版。

立项之初，我和我的合伙人之间曾有过激烈的意识层面的碰撞，碰撞的根源就在于开源和商业化之间的根本矛盾。开源如何盈利？不商业化的话，我们如何保持温饱？就算开源了，怎么确保能吸引足够多的优秀的开发者参与共创？

因为我们都是技术出身，也都是热衷于开源事业的技术人，也都对开源有着发自内心的热情，所以，不管多少次的碰撞、争吵，最后都妥协到了这份情结之上。

• JAP 口号：Just auth for any app!
• JAP 目标：让身份链接无处可藏（干掉传统 Login 模块复杂的逻辑！）
• JAP 价值：方便开发者无缝对接任何第三方应用或者自有系统，提高开发效率，减少代码维护成本
• JAP 愿景：以开源的方式，受惠于开源社区，赋能于开发者。使之成为开发者生态内必不可少的“基础设施”，以期形成新的技术标准。

一、源于此（JA 的起源）

说起 [JustAuth] gitee.com/yadong.zhang/JustAuth 的起源其实很简单，除了源于对技术的热爱，另外一个重要原因就是因为技术人的“懒”。

从 16 年起， 我开始自己开发博客系统，并且集成了 QQ 和微博两个第三方平台的登录功能，在集成其 SDK 时，费了好大功夫去研究源码、查阅文档、测试 API。最苦恼的就是，因为每个平台的 SDK 规则不一致，所以，同样的功能，必须复制 N 个版本，然后去适配，最终导致的结果就是项目中多出了一大堆冗余的代码。如下：

这是当时集成 QQ 和微博的实现代码。其实，接触的平台多了，自会发现一些问题：

• 各个平台间相互割裂（硬伤，无法避免）
• 各个平台的 SDK（部分平台并没有现成的 SDK 可供使用）代码庞大、复杂
• 各个平台的 API 比较繁杂
• 国外网站的 API 文档阅读困难

这可以说也算是一个契机。

到了 18 年，当时 QQ 群里除了站长外，还有一些开发者，应这些朋友的要求，我开源了自己的第一个博客系统 [OneBlog]，随着使用者的增加，以及用户的需求，我准备重新接入第三方登录功能。

但是鉴于之前接入第三方登录时的“阴影”，我也因此萌生了要开发一款开箱即用的 Oauth 登录工具包。这也正是后来 JustAuth “诞生”的最大原因。归根结底，还是因为一个“懒”，因为我不想耗费过多的精力去每个平台翻阅文档，一遍又一遍的复制同样的代码，一遍又一遍的重写同一个功能，最主要的是我知道一定会有很多人碰到了和我一样的问题。

二、行于此（JA 的发展）

[JustAuth]自开源起， 就备受广大开发者的关注，这一点也是我很欣慰的，因为我知道，我开源的这个工具，起码不是一个“废材”。
细数 JustAuth 的迭代之路，到目前为止，已发布到了[v1.15.9]版本，回顾这一年多的路程，确实有一些需要记录的点。

• 2019-01-31 提交了第一行代码
• 2019-03-25 发布了 v1.0.0 ，当天就被收录到码云推荐项目名单中，一周内都位列日排行榜和周排行榜第一名
• 2019-03-27 正式发布 v1.0.1 版本到 maven 中央仓库
• 2019-05-20 第一位贡献者 [xkcoding]加入
• 2019-06-20 发布 v1.7.0 版本，重构了部分代码，jar 包由原来的 ​130+kb​ 优化到 ​110+kb​（by xkcoding）
• 2019-06-29 发布 v1.8.0 版本，这一版算是分水岭。修改 login 方法的参数为 AuthCallback，封装回调返回的参数，同时增加 code 和 state 参数校验，预防 CSRF，v1.8.0 之前的版本中是没有 state 这一概念的。
• 2019-07-16 第二位贡献者 [pengisgood]加入
• 2019-07-18 如梦技术的大佬[春哥]入群，后期好多需求和想法都有春哥的建议。春哥是 Spring Cloud 微服务开发核心 mica 的作者，同时像 avue、Pigx、bladex 等项目多多少少都有春哥的助力。
• 2019-07-19 发布 v1.9.0 版本，解决 v1.8.0 隐藏的大 bug，重构部分代码，优化代码结构，减少编译后的代码量
• 2019-07-21 JustAuth 正式喜提码云【GVP 】称号
• 2019-07-30 发布 v1.9.3 版本，扩展 state 缓存实现
• 2019-08-06 发布 v1.10.0 版本，简单封装极简版的针对 JustAuth 的 ​Log​ 工具类，去掉 slf4j 依赖。这一版开始支持开发者自定义 state 缓存插件（Redis、Memcache 等）
• 2019-09-04 发布 ​justauth-spring-boot-starter​，全面支持 SpringBoot 快速集成（by xkcoding）
• 2019-09-17 发布 v1.12.0 版本，添加 Nutzboot 版的 demo，正式支持由用户自定义扩展第三方授权登录。
• 2020-03-17 发布 v1.14.0 版本，集成 simple-http ，解放 ​hutool-http​ 强依赖，具体的 HttpUtil 实现，由用户自己去选择，JustAuth 不再强制干预用户对 http 工具的选择权
• 2020-06-24 发布 v1.15.5 版本，集成阿里云平台；登录成功后返回第三方用户原始数据
• 2020-06-30 发布 v1.15.6 版本，迁移“帮助文档”到独立网站 [justauth.wiki]，增加忽略校验 state 的功能
• 2020-09-11 发布 v1.15.7 版本，升级 Github Access Token 验证方式；JA 正式支持自定义 scope 参数，使 JA 的应用场景更广，而不仅仅是登录
• 2020-10-25 发布 v1.15.8 版本，升级 simple-http 版本 from 1.0.2 to 1.0.3, 修复 jdk11 的 httpclient 使用默认超时时间的问题
• 2021-01-01 发布 v1.15.9 版本，新增喜马拉雅、飞书、企业微信网页授权平台，升级 facebook api 版本。

到目前（2021/1/19）为止，JA 取得的成绩：

• 增长趋势

• 已获 star： ​gitee(4.5k)​、 ​github(9.8k)​
• 2019 年 7 月份获得 Gitee GVP 称号
• 2019 年 8 月份 Github 上最热门的 Java 开源项目
• 目前收集到的使用用户（包含企业、各热门商业项目、个人项目等）：

并且还有很多企业也在使用 JA 实现第三方授权登录，不过由于企业方不方便公开所以并未加到列表中。

• 证书

如果您现在也在使用 JA，并且愿意与我们共享，请提交到如下地址（任选一个）：

• github.com/justauth/JustAuth/issues/17
• gitee.com/yadong.zhang/JustAuth/issues/IZ2T7

我们承诺，仅将获取到的信息，用于 JA 官网、项目 Readme 文档或者官方推荐文章中，不会用于其他任何非法、违规或者对用户不利的场景中。

三、愿于此（JA 的未来）

Is that all? No, not enough!

JA 能取得目前的成绩，全靠各位开发者/组织/企业/社区伙伴的支持，我们也在这儿衷心的感谢各位领导、各位朋友以及各位社区内的小伙伴。

虽然 JA 目前的成绩算是挺好，但我们不愿止步于此，不愿意让 JA 仅止步于 “第三方登录”，我们想做的更好，因此我们准备正式立项“JAP”！

JAP 是什么？

JAP 是一款开源的认证中间件，基于模块化设计，并且与业务高度解耦，使用起来非常灵活，开发者可以毫不费力地将 JAP 集成到任何 web 应用程序中，就像集成 JA 一样，简单方便。

JAP 要做的是为所有需要身份认证的应用提供一套标准的解决方案，集成所有 APP。方便开发者无缝对接任何第三方应用或者自有系统。

• JAP 口号：Just auth into any app!
• JAP 目标：让身份链接无处可藏
• JAP 价值：方便开发者无缝对接任何第三方应用或者自有系统，提高开发效率，减少代码维护成本
• JAP 愿景：以开源的方式，受惠于开源社区，赋能于开发者。使之成为开发者生态内必不可少的“基础设施”，以期形成新的技术标准。
• JAP 开源地址：gitee.com/fujieid/jap

JAP 开发背景？

JA 是为了干掉第三方登录，JA Plus 是为了干掉整个登录相关的业务模块。

JAP 有什么特点？

• 单点登录：一处登录，处处通行
• 开箱即用：API 设计趋近于白话
• 多平台：
  • 国内外数十家第三方平台（基于 JustAuth）
  • OAuth（OIDC） 协议的平台，内置国内外常见平台
  • SAML 协议的平台，内置国内外常见平台
• 业务解耦：JAP 不深入具体的业务，只将授权认证方面的功能抽象出一套标准的组件，方便任意系统快速对接
• 模块化：JAP 基于模块开发，基本做到，用哪种引哪种
• 统一标准：一切内置实现或者自定义的实现，都基于标准的策略
• 多语言支持：Java、Python、Go、Node 等

JAP 有什么功能？

• 集成账号密码登录
  • 支持自有系统账号
  • 支持第三方 API 接入
• 集成第三方登录（基于 JA）
• 集成 OAuth 登录（包含 OIDC）
  • 提供 Server 端服务
  • 支持自定义第三方服务
• 集成 LDAP 登录
• 集成 SAML 登录
  • 提供 Server 端服务
  • 支持自定义第三方服务
• 集成 AD 域登录
• MFA
• 账号退出
• 多语言支持
• …

JAP 适用于哪些场景？

• 新项目立项，你们需要研发一套包含登录、认证的系统
• 现有登录模块为自研，但是新一轮的技术规划中，你们想将登录认证模块重构，以更加灵活的架构适应后面的新需求，比如：集成 MFA 登录、集成 OAuth 登录等
• 你们的项目太多，每个项目都需要登录认证模块，想解决这种重复劳动的问题
• 从长远方面考虑，公司或组织或个人需要一套标准的、灵活的、功能全面的登录认证功能
• 你们不想将研发成本放到登录认证这种必须但想做完善又需要花费大量时间成本、人力成本的事情上，希望有一个中间件可以完美集成登录认证功能，使研发人员有更多的时间和精力投入到业务开发中，提高研发产能和研发效率
• 你们除了需要对接标准的身份提供商外，还有一些非标准的身份提供商，需要投入研发人员单独定制开发
• 你们企业种用到的开发语言较多，比如：Java、Python、Node 等，每种语言对应的系统，都要使用不同语言实现相同的登录认证功能
• 你们需要研发一个支持 OAuth 登录的 Web 应用程序
• 你们想让自己的系统支持对外提供 OAuth 服务
• 你们需要研发一个支持 SAML 登录的 Web 应用程序，但又苦于 SAML 那庞大而繁琐的业务流程和配置
• 你们想让自己的系统支持对外提供 SAML 服务
• 你们想研发一个支持 LDAP 登录的程序，但又不知道如何入手
• 你们觉得传统的账号密码非常脆弱，所想让用户使用一次性的手机验证码或邮箱验证码进行登录
• 你们企业希望联合其现有的企业用户目录，以允许员工使用其现有的企业凭据登录各种内部和第三方应用程序。
• …

JAP 常见问题有哪些？

JAP 不支持具体的业务操作吗？

JAP 针对用户、应用等业务数据，只提供标准的业务接口，不提供数据库层面的支持。JAP 要做的是为广大开发者提供一套技术标准，既然是标准，那就不能依赖于任何和具体业务相关的逻辑。不管你们的系统是用的 MySQL、Oracle、SQLlite、Redis、MongoDB 还是其他的，JAP 通通不关心。JAP 对外提供标准接口，业务端只需要按需实现 JAP 的接口即可，这种设计能在最大程度上增加它的灵活性，使它不受限于某一具体的数据库实现方案。

JAP 可以用到企业级项目吗？

当然，JAP 的价值就在于：方便开发者无缝对接任何第三方应用或者自有系统，提高开发效率，减少代码维护成本。所以对于企业来说，这是一个降本增效的功能。JAP 基于模块化开发，并且不侵入业务系统，可以十分方便的集成到企业内部各个系统或者统一的登录认证网关中。

JAP 可以商用吗？

JAP 基于 LGPL 3.0 协议。商用分为以下两种情况：

• LGPL 允许商业软件通过类库引用(link)方式使用而不需要开源商业软件的代码。这使得采用 LGPL 协议的开源代码可以被商业软件作为类库引用并发布和销售。
• 如果修改 LGPL 协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用 LGPL 协议。因此 LGPL 协议的开源代码不适合通过修改和衍生的方式做二次开发的商业软件采用。

四、我们需要什么？

我们的愿景（以开源的方式，受惠于开源社区，赋能于开发者。使之成为开发者生态内必不可少的“基础设施”，以期形成新的技术标准）决定了我们即将要走的这条道路的艰难性无疑是巨大的。

我们不仅仅只是想把这款作品推广到国内众多开发者、组织和企业用户身边，让他们享受开源带来的便利；我们还要把这个作品推向更广阔的空间，推向国际，让更多的开发者、组织和企业了解并真真正正的使用这个项目、受惠于这个项目。

既然我们选择了开源，选择了奉献，选择了这将“一条道走到黑”的路，就需要我们能一直走下去。但开源的路何其漫长、何其孤独，“路漫漫其修远兮，吾将上下而求索”。

我们知道，仅凭我们自己的力量就想推动这个项目发扬光大、普惠开发者还远远不够，我们也深信，只有发挥团队的力量，集思广益，才能打造出一个真正优秀的、真正受欢迎的、真正标榜的能屹立于开源之林的顶尖项目！所以我们需要寻找一些真诚的、志同道合的、靠谱的合作伙伴和战友。

是的，我们准备做的这一切，都是源于我们对技术的热爱，对开源的热爱，以及对国内开源事业的热爱。因此，我们也需要找到和我们有相同兴趣、爱好、目标的人来一起完成这件有意义的事。

如果你也对 JAP 感兴趣，请将以下信息发给我们：

• 个人姓名、邮箱（邮箱或者手机二选一）
• 个人开源首页（Gitee 或者 Github）
• 个人的说明，比如做过哪些开源项目或者参与过哪些知名的开源项目

JAP 进度

• 2021 年 01 月 12 日建立项目（闭源开发）：gitee.com/fujieid/jap
• 2021 年 01 月 19 日正式开源：gitee.com/fujieid/jap
• 开源后 1 小时获得红薯推荐

• 截止 2021 年 01 月 19 日 20 时获得 star 42 个
• 访问 IP 246 个
  

说给我的支持者

在 JAP 开源出来不久，我就被项目评论区的一条留言吸引到：

这位兄弟的一席话，让我很感动。做开源的乐趣大概就在此吧，开源项目作者和开发者之间相互成就。

再次感谢陪我一路走来的诸位朋友！