这是一个创建于 1401 天前的主题，其中的信息可能已经有所发展或是发生改变。
JA Plus 故事
程序员的故事如此简单之绕不过去的开源情结
我们准备做一件伟大的事，也可以说是一件真真正正普惠的事。
絮
是的，你没有看错，就是“絮”而非“序”，请允许我絮叨二三。
我们即将要做的，我们认为是一件伟大的事，也可以说是一件真真正正普惠的事。我们要开发一款真真正正国产的并且未来将会走向国际的完全开源的产品 - Just Auth Plus （以下简称 “JAP”）。
JAP 是 JustAuth（以下简称 “JA”） 的升级版。
立项之初，我和我的合伙人之间曾有过激烈的意识层面的碰撞，碰撞的根源就在于开源和商业化之间的根本矛盾。开源如何盈利？不商业化的话，我们如何保持温饱？就算开源了，怎么确保能吸引足够多的优秀的开发者参与共创？
因为我们都是技术出身，也都是热衷于开源事业的技术人，也都对开源有着发自内心的热情，所以，不管多少次的碰撞、争吵，最后都妥协到了这份情结之上。
- JAP 口号：Just auth for any app!
- JAP 目标：让身份链接无处可藏（干掉传统 Login 模块复杂的逻辑！）
- JAP 价值：方便开发者无缝对接任何第三方应用或者自有系统，提高开发效率，减少代码维护成本
- JAP 愿景：以开源的方式，受惠于开源社区，赋能于开发者。使之成为开发者生态内必不可少的“基础设施”，以期形成新的技术标准。
一、源于此（ JA 的起源）
说起 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 版本，迁移“帮助文档”到独立网站 https://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，并且愿意与我们共享，请提交到如下地址（任选一个）：
我们承诺，仅将获取到的信息，用于 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 开源地址：https://gitee.com/fujieid/jap
JAP 开发背景？
JA 是为了干掉第三方登录，JA Plus 是为了干掉整个登录相关的业务模块。
JAP 有什么特点？
- 单点登录：一处登录，处处通行
- 开箱即用：API 设计趋近于白话，类似并参考 JustAuth
-
多平台：
- 国内外数十家第三方平台（基于 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 协议的开源代码不适合通过修改和衍生的方式做二次开发的商业软件采用。
四、我们需要什么？
我们的愿景（以开源的方式，受惠于开源社区，赋能于开发者。使之成为开发者生态内必不可少的“基础设施”，以期形成新的技术标准）决定了我们即将要走的这条道路的艰难性无疑是巨大的。
我们不仅仅只是想把这款作品推广到国内众多开发者、组织和企业用户身边，让他们享受开源带来的便利；我们还要把这个作品推向更广阔的空间，推向国际，让更多的开发者、组织和企业了解并真真正正的使用这个项目、受惠于这个项目。
既然我们选择了开源，选择了奉献，选择了这将“一条道走到黑”的路，就需要我们能一直走下去。但开源的路何其漫长、何其孤独，“路漫漫其修远兮，吾将上下而求索”。
我们知道，仅凭我们自己的力量就想推动这个项目发扬光大、普惠开发者还远远不够，我们也深信，只有发挥团队的力量，集思广益，才能打造出一个真正优秀的、真正受欢迎的、真正标榜的能屹立于开源之林的顶尖项目！所以我们需要寻找一些真诚的、志同道合的、靠谱的合作伙伴和战友。
就像我在之前直播分享 JustAuth 时（前情回顾：由表入里全面介绍 JustAuth）表达过的一个观点一样：和一群志同道合的朋友一起做一件喜欢的事情，是一种幸福。巧合的是，高瓴资本创始人兼首席执行官张磊也提过类似的观点：高瓴资本张磊：找一帮你喜欢的、真正靠谱的人，一起做有意思的事。
是的，我们准备做的这一切，都是源于我们对技术的热爱，对开源的热爱，以及对国内开源事业的热爱。因此，我们也需要找到和我们有相同兴趣、爱好、目标的人来一起完成这件有意义的事。
如果你也对 JAP 感兴趣，请将以下信息发给我们：
- 个人姓名、邮箱（邮箱或者手机二选一）
- 个人开源首页（ Gitee 或者 Github ）
- 个人的说明，比如做过哪些开源项目或者参与过哪些知名的开源项目
发送邮件到：[email protected]
更多详情，请参考链接JAP 文档中心
五、社区相关
我们会高标准、高要求我们的核心社区伙伴。如果你想加入到我们的核心团队中，如果你想参与到 JAP 项目社区，请仔细阅读以下内容：
成员要求
所有成员基本要求
- 尊重开源，热爱开源。尊重是前提，热爱是目的。
- 团结友善，乐于协作。
- 热爱技术，擅用技术。
- ...
核心成员要求
如果你想成为社区的核心成员，请满足以下条件：
- 需至少有一个开源的 star 数超 1k 的项目
- 有过开源社区参与、维护、管理经验
- 对身份认证相关内容有个人成熟的观点、看法或愿望
- ...
如何成为核心成员
-
如满足以上条件（核心成员要求），请按照以下格式，发送邮件到我们的官方邮箱（[email protected]）：
- 姓名
- 个人网站（如有）
- 开源项目地址（不限于 Github 、Gitee 、Bitbucket 等）
- 为什么要加入社区核心团队（个人简要说明）
- 如不满足以上条件，并且仍想加入我们的核心团队，请简要描述你的个人履历，发送至我们的官方邮箱：[email protected]
成员福利
基本成员福利
- 享有该共创项目的官方提名权。
- 享有官方举办的一切基于该共创项目的盈利活动（包括但不限于技术大会、沙龙、企业培训等）的优先参与权和门票（如果有）优惠权。
- ...
核心成员福利
- 所有归于该项目的盈利（包括但不限于技术支持、技术服务等），统一按照贡献内容、贡献质量分配。
- 根据贡献内容、贡献质量，永久享有该共创项目的一切“Title”，并且在合理合法合规的前提下可以任意使用该项目的一切权利（署名权等）。
- 官方举办的一切基于该项目的盈利活动（包括但不限于技术大会、沙龙、企业培训等）的免费参与权。
- 与其他核心成员共同享有“社区权力”。
- 享有 北京符节科技有限公司 所有产品优惠权。包括但不限于：免费使用、官方优惠券等。
- ...
违规项
- 恶意篡改、删除项目代码。
- 恶意扰乱社区。
- 发布谩骂、歧视、仇恨、反政治等言论。
- 基于该共创项目，删除 License 后私自 “二开”（再次开源）。
- 联合其他核心成员，以小帮派的形式行使社区权力以达到自己的目的，破坏社区的和平性。
- ...
社区权力
由核心成员共同拥有。
- 享有对该项目普通成员（参与者、贡献者）所贡献的代码和文件的表决权（予以对提交请求的同意、拒绝等权力）。
- 享有对该项目发展规划的表决权。
- 享有对该项目核心成员的罢免权（仅针对违规成员）。
- ...
社区规划
-
组建团队（社区）
- 寻找核心成员，需满足上面提到的“核心成员要求”。
-
打造 JAP 品牌
- 编码
- 编码
- 编码
- 开源社区布道
- 寻找资本投资
- 拓宽海外场景
- 完成愿景
- ...
更多详情，请参考链接JAP 文档中心 - 社区相关
JAP 进度
- 2021 年 01 月 12 日建立项目（闭源开发）： https://gitee.com/fujieid/jap
- 2021 年 01 月 19 日正式开源： https://gitee.com/fujieid/jap
- 开源后 1 小时获得红薯推荐
- 截止 2021 年 01 月 19 日 20 时获得 star 42 个
- 访问 IP 246 个
开源故事
插播一条消息，欢迎给 JustAuth 、OneBlog 等项目提交过代码的同学，或者提交过 Issue 的同学投稿 Gitee 的 [开源故事] 专题，投稿地址：
说给我的支持者
在 JAP 开源出来不久，我就被项目评论区的一条留言吸引到：
这位兄弟的一席话，让我很感动。做开源的乐趣大概就在此吧，开源项目作者和开发者之间相互成就。
再次感谢陪我一路走来的诸位朋友！
JAP 开源地址：https://gitee.com/fujieid/jap
目前尚无回复
Select Language