對不起，這里沒有代碼，因為我正在尋找一個更好的想法，或者我是否在正確的軌道上？
我有兩個網站，讓我們稱它們為A和B.
。A是一個暴露在互聯網上的網站，只有擁有有效賬戶的用戶才能訪問。
B 是一個內部（行內網）網站，有（使用 Active Directory 的 Windows 認證）。我希望應用程式 B（內部網）為應用程式 A 創建用戶。
應用程式 A 正在使用內置的 ASP.NET JWT 令牌驗證。
我的想法是在外網網站（A）上公開一個 Api，讓（B）訪問這個 API。我可以使用 CORS 來確保只有 (B) 可以訪問端點，但我不確定這是否是足夠好的保護？我們將從第三方公司進行安全滲透測驗，所以這可能無法通過安全測驗？
或者
我可以使用物體框架來手動更新AspnetUsers表。我不知道這是否可行，也不知道這是否是正確的方法。
有什么其他解決方案嗎？
uj5u.com熱心網友回復：
在我看來，不要用外部解決方案暴露你的內部義務，如實施API等...
只需共享資料庫，讓B可以訪問。這樣一來，服務器管理就是唯一的安全問題，沒有人知道你是如何作業的。此外，你如何為每個人實作用戶認證（無論是Windows認證還是JWT）并擁有一個獨立的基礎設施，這一點并不重要。
uj5u.com熱心網友回復：
它們是這一問題的多種解決方案。然后，它真的取決于你的具體標準。
你可以選擇：
但是，它們都有起伏，我將嘗試為你分解它們。
API解決方案
優點：- 單一責任。
- 單一責任，你只有一段代碼接觸到這個資料庫，這使得它更容易減輕副作用 它是 "面向未來的"，你可以很容易地讓更多的服務使用這個 api.
缺點：
- 攻擊面增加
- 攻擊面增加，API是在公共場合，所以會被第三方試圖玩弄。
- 隨著資料庫模型的變化而維護 API（又多了一個需要維護的部分）
- 不是最快的解決方案。
- 并不是實施速度最快的解決方案。
資料庫直接訪問
上級：下降:
- 資料庫模型需要維護兩次 。
- 遷移 部署需要協調，難以維護。
- 使系統更容易出錯。 。
發布時的遷移
升級：下方：
- 不靈活
- 不靈活 對用戶來說非常慢。
- 許多部署 手作業業（隨著時間的推移，成本會很高）。
在我看來，我建議你使用API，用OAuth機制確保API的訪問。OAuth的實施太耗費時間了。也許你可以嘗試一些更簡單的Auth協議。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/309877.html
標籤：