大家好，我是張飛洪，現(xiàn)就職廈門藍(lán)略數(shù)字科技，感謝您的閱讀，我會(huì)不定期和你分享學(xué)習(xí)心得，希望我的文章能成為你成長(zhǎng)路上的墊腳石，讓我們一起精進(jìn)。

1.當(dāng)“登錄”變得不再簡(jiǎn)單

登錄組件雖不起眼，但是如果你認(rèn)真梳理其發(fā)展歷史，你會(huì)發(fā)現(xiàn)它就像一個(gè)從“鑰匙開鎖”升級(jí)到“刷臉進(jìn)門”的過(guò)程。
最早就是簡(jiǎn)單的用戶名密碼框，像填表格一樣；后來(lái)加了驗(yàn)證碼、密碼強(qiáng)度提示，還能用微信或谷歌一鍵登錄；
現(xiàn)在更厲害了，短信驗(yàn)證、指紋刷臉、甚至點(diǎn)郵件里的鏈接就能登，連密碼都不用記！
未來(lái)可能連手指都不用動(dòng)，AI看一眼就知道是你。
整個(gè)過(guò)程就是越變?cè)胶?jiǎn)單、越安全，就像從鑰匙→密碼鎖→人臉識(shí)別的智能門鎖進(jìn)化史。

登錄組件的本質(zhì)是解決身份認(rèn)證的問題，也就是說(shuō)，你要告訴系統(tǒng)你是何方神圣，你的身份證號(hào)碼是多少。
當(dāng)你們公司只有一個(gè)系統(tǒng)的時(shí)候，你很好辦，因?yàn)槟阒恍枰涀∫粋€(gè)賬號(hào)和密碼。隨著系統(tǒng)不斷累加，一般百人以上的公司，系統(tǒng)都不可能只有一套。
我之前呆過(guò)的安踏，系統(tǒng)就更多了，有OA，ERP，WMS，訂單管理系統(tǒng)，財(cái)務(wù)系統(tǒng)，資產(chǎn)管理系統(tǒng)……
對(duì)跨系統(tǒng)用戶，如何管理自己的多個(gè)賬戶是非常麻煩的，因?yàn)槟悴豢赡苡涀∧敲炊噘~戶和密碼，如果密碼統(tǒng)一，安全可能會(huì)存在隱患。
這就是登錄在發(fā)展中冒出的系統(tǒng)多樣導(dǎo)致的賬號(hào)密碼混亂，甚至安全泄露的問題。
傳統(tǒng)身份認(rèn)證的局限性

2.1.多系統(tǒng)身份管理困難

從技術(shù)層面來(lái)看，對(duì)集成類的系統(tǒng)，比如廈門會(huì)展中心，或者地鐵，機(jī)場(chǎng)，軌道，醫(yī)院等中型或者中大型項(xiàng)目，他們需要的供應(yīng)商提供的系統(tǒng)可能有十幾種，每個(gè)系統(tǒng)就像一根煙囪，每個(gè)系統(tǒng)都維護(hù)有一套自己的用戶表，如何統(tǒng)一管理這些用戶、組織機(jī)構(gòu)和權(quán)限，如何減少維護(hù)成本是一個(gè)老大難題。

2.2.授權(quán)邏輯散落難統(tǒng)一

想象一下：公司每個(gè)業(yè)務(wù)系統(tǒng)都像一棟獨(dú)立大樓，A樓用門禁卡，B樓要密碼，C樓甚至靠保安認(rèn)臉……結(jié)果員工每天光進(jìn)門就要折騰半天，管理員更是崩潰——權(quán)限規(guī)則散落在各處，改個(gè)權(quán)限得跑遍所有系統(tǒng)，稍不留神就漏掉某個(gè)角落。
這就是典型的“授權(quán)邏輯碎片化”問題：
● 各搞各的：每套系統(tǒng)自己管理權(quán)限，標(biāo)準(zhǔn)不統(tǒng)一
● 越管越亂：?jiǎn)T工離職后，可能在某冷門系統(tǒng)里權(quán)限還在
● 效率黑洞：跨系統(tǒng)協(xié)作時(shí)，反復(fù)申請(qǐng)權(quán)限拖慢進(jìn)度

2.3無(wú)法支撐現(xiàn)代化集成需求

在各個(gè)中大型集成項(xiàng)目中，各業(yè)務(wù)系統(tǒng)就像一個(gè)個(gè)獨(dú)立煙囪，無(wú)法滿足 SSO、OAuth 等現(xiàn)代化的集成需求：

1. 認(rèn)證方式割裂：售票系統(tǒng)用LDAP、安防系統(tǒng)用本地賬號(hào)、商業(yè)系統(tǒng)用微信登錄...SSO根本無(wú)從談起
2. 權(quán)限數(shù)據(jù)孤島：每個(gè)系統(tǒng)維護(hù)自己的用戶表和角色配置，OAuth所需的統(tǒng)一授權(quán)中心無(wú)法建立
3. 集成成本暴增：每對(duì)接一個(gè)新系統(tǒng)，都要重新開發(fā)用戶同步邏輯，運(yùn)維團(tuán)隊(duì)疲于應(yīng)付賬號(hào)沖突/權(quán)限不一致問題
   這直接導(dǎo)致：
   ● 用戶要記多套密碼
   ● 安全審計(jì)時(shí)權(quán)限漏洞百出
   ● 想對(duì)接智慧服務(wù)平臺(tái)？先解決十幾個(gè)系統(tǒng)的賬號(hào)打通問題。

2.4.權(quán)限粒度無(wú)法適配復(fù)雜組織

在多數(shù)中小型系統(tǒng)中，“權(quán)限”常常只體現(xiàn)在“用戶擁有某個(gè)角色”或“用戶能否訪問某個(gè)菜單”，這是一種典型的粗粒度授權(quán)模型。它的問題在于：一旦面對(duì)復(fù)雜組織結(jié)構(gòu)、動(dòng)態(tài)職責(zé)分配、多維度授權(quán)時(shí)，這種模型就會(huì)失效，變得不可控、不可維護(hù)。

2.4.1.權(quán)限邊界模糊

比如，傳統(tǒng)做法中，一個(gè)角色往往直接綁定菜單或頁(yè)面訪問權(quán)限，用戶綁定角色后，即擁有所有角色權(quán)限，無(wú)法做到精確到“數(shù)據(jù)級(jí)”、“操作級(jí)”的控制。更具體一點(diǎn)，某公司“銷售主管”角色能查看所有客戶？那臨時(shí)調(diào)崗的新人主管是不是也能？有沒有辦法限定他只能看“華東區(qū)域客戶”？顯然，傳統(tǒng)的“角色綁定菜單”做法無(wú)法滿足。

2.4.2.忽視組織結(jié)構(gòu)的維度

很多傳統(tǒng)權(quán)限設(shè)計(jì)只是“用戶 — 角色 — 權(quán)限”的三層模型，完全忽略了組織結(jié)構(gòu)（部門、崗位、層級(jí)）。
但真實(shí)企業(yè)場(chǎng)景往往是：
● 同一個(gè)角色在不同部門，權(quán)限邊界應(yīng)不同；
● 同一個(gè)人在不同系統(tǒng)中身份不一致（開發(fā)部是“負(fù)責(zé)人”，運(yùn)維部是“操作員”）；
● 員工調(diào)崗/兼職/派遣，權(quán)限應(yīng)跟隨“崗位職責(zé)”，而非固定綁定。
沒有組織維度的權(quán)限模型，注定在大型企業(yè)內(nèi)推不動(dòng)。

2.4.3.權(quán)限缺乏策略表達(dá)力

現(xiàn)代系統(tǒng)中，對(duì)權(quán)限的要求已經(jīng)不僅僅是“誰(shuí)能訪問什么”，而是：
● 誰(shuí)，在什么時(shí)間段，在哪種上下文條件下，能做什么操作；
● 支持 ABAC（基于屬性的訪問控制）、PBAC（基于策略的訪問控制）等模型；
● 比如：“僅允許財(cái)務(wù)人員在工作日 9 點(diǎn)到 18 點(diǎn)操作大額轉(zhuǎn)賬”——這種規(guī)則傳統(tǒng)權(quán)限系統(tǒng)完全無(wú)法描述。

2.4.4.權(quán)限難以審計(jì)與復(fù)用

由于權(quán)限都是分散在代碼中或配置中手動(dòng)管理的：
● 沒有集中視圖可以查看某用戶到底擁有哪些權(quán)限；
● 每個(gè)系統(tǒng)重新定義權(quán)限，重復(fù)造輪子，策略不一致；
● 無(wú)法做到統(tǒng)一授權(quán)、統(tǒng)一回收、統(tǒng)一審計(jì)。
總結(jié)一句話：傳統(tǒng)權(quán)限模型只適合靜態(tài)、簡(jiǎn)單、單系統(tǒng)的小場(chǎng)景，面對(duì)復(fù)雜、多變、組織化、多系統(tǒng)的現(xiàn)實(shí)環(huán)境，它就是一把鈍刀。”

2.5.無(wú)審計(jì)無(wú)集中安全策略

在傳統(tǒng)系統(tǒng)中，認(rèn)證授權(quán)往往由每個(gè)業(yè)務(wù)系統(tǒng)自行實(shí)現(xiàn)，缺乏統(tǒng)一規(guī)劃。這樣的設(shè)計(jì)雖然短期內(nèi)開發(fā)簡(jiǎn)單，但從安全和合規(guī)的角度看，隱患極大：

2.5.1.用戶行為無(wú)法追蹤，操作行為不可溯源

● 多數(shù)系統(tǒng)沒有登錄、登出、授權(quán)失敗、權(quán)限變更等行為的日志記錄；
● 無(wú)法回答 “誰(shuí)、在什么時(shí)間、對(duì)什么資源、做了什么操作” 這種最基本的審計(jì)問題；
● 一旦發(fā)生安全事故，如敏感數(shù)據(jù)泄露、越權(quán)訪問、濫用權(quán)限，根本無(wú)法回溯和定位責(zé)任人。
例如：某財(cái)務(wù)人員非法導(dǎo)出客戶數(shù)據(jù)，系統(tǒng)無(wú)登錄審計(jì)、無(wú)導(dǎo)出日志，甚至不知道導(dǎo)出是他做的。

2.5.2.安全策略分散，防御體系形同虛設(shè)

● 登錄失敗次數(shù)限制？某系統(tǒng)有，某系統(tǒng)沒有；
● 密碼復(fù)雜度規(guī)則？每個(gè)系統(tǒng)都自己定，難以統(tǒng)一修改；
● 是否強(qiáng)制 HTTPS？是否開啟雙因素認(rèn)證？是否有登錄地限制？——全靠開發(fā)習(xí)慣；
結(jié)果就是：看似都有“權(quán)限”，實(shí)則安全空心化。

2.5.3.用戶和權(quán)限無(wú)法集中管理，難以合規(guī)

● 多個(gè)系統(tǒng)各自維護(hù)用戶賬號(hào)、權(quán)限、角色數(shù)據(jù)；
● 用戶離職或變更崗位，只能人工通知各系統(tǒng)管理員去“刪賬號(hào)”；
● 一旦遺漏，就會(huì)留下“僵尸賬號(hào)”，形成權(quán)限漂移與越權(quán)風(fēng)險(xiǎn)；
例如，一名項(xiàng)目經(jīng)理離職，但他在某個(gè)舊系統(tǒng)中仍保留管理員權(quán)限，可繼續(xù)操作核心業(yè)務(wù)數(shù)據(jù)，這是典型的合規(guī)紅線問題。

2.5.4.無(wú)法滿足現(xiàn)代合規(guī)要求（等保、ISO、GDPR）

越來(lái)越多的企業(yè)必須通過(guò)：
● 網(wǎng)絡(luò)安全等級(jí)保護(hù)（等保 2.0/3.0）
● ISO 27001 信息安全管理體系認(rèn)證
● GDPR / 數(shù)據(jù)出境監(jiān)管政策
這些合規(guī)標(biāo)準(zhǔn)都明確要求：
● 賬戶統(tǒng)一管理、權(quán)限最小化配置、行為可審計(jì)、安全策略集中控制
如果沒有云身份或類似統(tǒng)一身份平臺(tái)，企業(yè)根本無(wú)法在技術(shù)上支撐這些合規(guī)要求。

3.什么是IDaaS？

到底什么是IDaaS，它解決了什么問題？有了上面兩大點(diǎn)的鋪墊，我相信你應(yīng)該很清楚它要解決什么問題了。
我們還是從專業(yè)上對(duì)它做一個(gè)定義
● 定義：Identity as a Service，統(tǒng)一的身份基礎(chǔ)設(shè)施
● 功能概覽（可用簡(jiǎn)圖呈現(xiàn)）：
○ 用戶中心 + 權(quán)限中心 + OAuth2/OIDC 提供方 + 安全策略平臺(tái)
● 它如何解決上面提到的每一個(gè)問題：
○ 多系統(tǒng)統(tǒng)一認(rèn)證授權(quán)
○ 統(tǒng)一用戶身份與權(quán)限入口
○ 系統(tǒng)級(jí)審計(jì)追蹤與策略防護(hù)
○ 易于擴(kuò)展，適配第三方登錄、多租戶等復(fù)雜場(chǎng)景

4.為什么不是用 ABP 自帶的模塊？

我們知道ABP采用的認(rèn)證授權(quán)也經(jīng)過(guò)了一次更替，從原來(lái)的IdentityServer4切換到OpenIddict，但是不管怎么切換，如果您有使用過(guò)，你會(huì)發(fā)現(xiàn)它能主要功能還是偏中小或者個(gè)人。如果要支持中大型企業(yè)的管理需要，它的能力還是很不夠的，包括我在上面提到的傳統(tǒng)身份認(rèn)證的局限性，它無(wú)法很好的解決。于是市面上出現(xiàn)了很多的IDaaS開源產(chǎn)品，但是從使用體驗(yàn)來(lái)看還是非常糟糕的。

4.1.缺乏靈活的權(quán)限建模

僅支持“用戶-角色-權(quán)限”三層結(jié)構(gòu)（RBAC），缺少：
● 基于組織/崗位的權(quán)限繼承（Org-Based）
● ABAC/PBAC 動(dòng)態(tài)授權(quán)策略
● 資源操作級(jí)控制（Resource + Action）
權(quán)限定義較粗，無(wú)法支撐復(fù)雜企業(yè)級(jí)授權(quán)策略（如跨組織授權(quán)、項(xiàng)目級(jí)特權(quán)、數(shù)據(jù)維度訪問控制）。

4.2.可視化管理體驗(yàn)落后 / 缺失

● IdentityServer4和OpenIddict的UI比較落后，交互體驗(yàn)也非常糟糕
● 權(quán)限配置、Scope 管理、用戶群組管理需要手工填表，非業(yè)務(wù)友好
● 對(duì)非開發(fā)人員非常不友好，產(chǎn)品落地成本高，依賴開發(fā)團(tuán)隊(duì)介入使用

4.3.接入復(fù)雜，缺乏“標(biāo)準(zhǔn)應(yīng)用模板”

● 雖然支持 OAuth2 / OIDC，但接入方式零散、沒有通用 SDK
● 缺少“第三方系統(tǒng)接入模板”（如：接 GitLab、Jenkins、釘釘、企業(yè)微信）
● 無(wú)可視化客戶端注冊(cè)入口
導(dǎo)致客戶系統(tǒng)接入認(rèn)證服務(wù)時(shí)體驗(yàn)極差，阻礙 IDaaS 落地

4.4.缺乏完整的賬號(hào)生命周期管理

● 如賬號(hào)注冊(cè)、審批、自動(dòng)禁用、失活提醒、離職回收、繼承授權(quán)等
● 大多僅提供注冊(cè)/刪除 API，無(wú)產(chǎn)品級(jí)“流程視角”
權(quán)限殘留、賬號(hào)泛濫、合規(guī)風(fēng)險(xiǎn)增加

4.5.缺乏審計(jì)日志、風(fēng)控策略等合規(guī)能力

● 登錄行為、權(quán)限變更等日志記錄不全或未內(nèi)置展示界面
● 無(wú)安全策略集中管理（IP 限制、2FA、異常行為提醒等）
不符合等保、ISO 27001、GDPR 等安全規(guī)范

5.總結(jié)

總之，IDaaS 是“統(tǒng)一”的開始，也是系統(tǒng)互聯(lián)的基石。它不僅解決了“企業(yè)內(nèi)每個(gè)系統(tǒng)都要重復(fù)建設(shè)用戶模塊”的痛點(diǎn)，更重要的是，通過(guò)提供支持多租戶的統(tǒng)一身份入口、靈活的分級(jí)授權(quán)體系、細(xì)粒度的權(quán)限管理和全局審計(jì)能力，IDaaS 成為企業(yè)集團(tuán)信息化建設(shè)的“數(shù)字身份中樞”。
對(duì)于集團(tuán)型企業(yè)，IDaaS 可實(shí)現(xiàn)母子公司的賬號(hào)體系統(tǒng)一管理，同時(shí)支持各業(yè)務(wù)單元獨(dú)立運(yùn)營(yíng)；對(duì)于 SaaS 服務(wù)商，IDaaS 提供標(biāo)準(zhǔn)化的租戶隔離與權(quán)限模板，讓身份服務(wù)本身成為可復(fù)用的運(yùn)營(yíng)能力。
有了 IDaaS，無(wú)論是企業(yè)內(nèi)部系統(tǒng)還是云端 SaaS 應(yīng)用，都可以共享用戶體系、復(fù)用權(quán)限模型，輕松實(shí)現(xiàn)跨組織單點(diǎn)登錄、多端統(tǒng)一認(rèn)證和業(yè)務(wù)協(xié)同。開發(fā)團(tuán)隊(duì)既能滿足復(fù)雜的企業(yè)治理要求，又能快速支持 SaaS 化運(yùn)營(yíng)，真正讓身份管理從“技術(shù)負(fù)擔(dān)”升級(jí)為“戰(zhàn)略資產(chǎn)”。