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，並且願意與我們共享，請提交到如下地址（任選一個）：
- https://github.com/justauth/JustAuth/issues/17
- https://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 開源地址：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）
- 個人的說明，比如做過哪些開源專案或者參與過哪些知名的開源專案
傳送郵件到：support@fujieid.com
更多詳情，請參考連結JAP 文件中心
五、社群相關
我們會高標準、高要求我們的核心社群夥伴。如果你想加入到我們的核心團隊中，如果你想參與到 JAP 專案社群，請仔細閱讀以下內容：
成員要求
所有成員基本要求
- 尊重開源，熱愛開源。尊重是前提，熱愛是目的。
- 團結友善，樂於協作。
- 熱愛技術，擅用技術。
- ...
核心成員要求
如果你想成為社群的核心成員，請滿足以下條件：
- 需至少有一個開源的 star 數超 1k 的專案
- 有過開源社群參與、維護、管理經驗
- 對身份認證相關內容有個人成熟的觀點、看法或願望
- ...
如何成為核心成員
- 如滿足以上條件（核心成員要求），請按照以下格式，傳送郵件到我們的官方郵箱（support@fujieid.com）：
- 姓名
- 個人網站（如有）
- 開源專案地址（不限於 Github、Gitee、Bitbucket 等）
- 為什麼要加入社群核心團隊（個人簡要說明）
- 如不滿足以上條件，並且仍想加入我們的核心團隊，請簡要描述你的個人履歷，傳送至我們的官方郵箱：support@fujieid.com
成員福利
基本成員福利
- 享有該共創專案的官方提名權。
- 享有官方舉辦的一切基於該共創專案的盈利活動（包括但不限於技術大會、沙龍、企業培訓等）的優先參與權和門票（如果有）優惠權。
- ...
核心成員福利
- 所有歸於該專案的盈利（包括但不限於技術支援、技術服務等），統一按照貢獻內容、貢獻質量分配。
- 根據貢獻內容、貢獻質量，永久享有該共創專案的一切“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