北京
在上一篇文章里，我們聊了OpenIddict是什么，以及它為什么能成為.NET開發圈里構建標準授權服務器的首選。框架本身足夠穩健，維護也很活躍，靈活性更是它的招牌。
但靈活性是有代價的。OpenIddict不會替你拿主意——它把工具交到你手里，怎么用全看你自己。放在安全領域，配置錯誤從來都不只是一個技術Bug，而是一個實打實的漏洞。
這篇文章就來看看開發者從零搭建OpenIddict時，最容易踩的幾個坑，以及這些坑一旦帶上生產環境，究竟會造成什么后果。
把開發環境證書直接丟上生產
OpenIddict把本地跑通的門檻壓得非常低。兩行方法調用，簽名和加密證書就到位了：
options.AddDevelopmentEncryptionCertificate() 和 options.AddDevelopmentSigningCertificate()，敲完之后一切正常運轉，看起來齊活兒了。
但這兩個方法生成的證書是臨時的，只存在于內存里。每次應用程序重啟，系統都會重新生成一套全新的證書——這也就意味著，重啟前簽發的所有令牌，在重啟那一刻全部作廢。用戶被強制登出，API調用開始報錯，刷新令牌直接失效。如果你在多實例負載均衡的環境下跑這套配置，局面會更麻煩：A實例簽發的令牌，B實例根本驗證不了。結果是持續不斷、毫無規律的身份驗證失敗，用戶一頭霧水，運維焦頭爛額。
從安全角度審視，開發證書同樣不該出現在任何面向真實用戶的環境里。它們對密鑰強度不做任何保證，沒有輪換策略，也不留審計痕跡。它們存在的唯一目的，就是降低開發時的摩擦，僅此而已。
正確的做法是提供持久化證書——從文件系統加載，或者從Windows證書存儲區里讀取。這些證書要能扛過重啟，并且在你應用的所有實例之間共享。這要求你在寫下第一行配置之前，就得搞清楚證書格式、密鑰存儲方式和輪換策略。看似多了幾步操作，但這是上線前必須補齊的基本功。
令牌生命周期太長——或者干脆沒設
OpenIddict允許你為每一種令牌單獨配置有效期：訪問令牌、刷新令牌、授權碼、身份令牌，全都可以精細控制。如果你不顯式設置，框架會用默認值。那些默認值本身不算離譜，但它們未必適配你自己的威脅模型。
開發者最容易在這里栽的跟頭，就是把訪問令牌的有效期設得太長。想象一下，一個有效期為24小時的訪問令牌一旦被盜，攻擊者就擁有了整整一個24小時的窗口來隨意使用它。在這段時間里，你幾乎沒有任何辦法讓這個令牌失效——除非你額外部署了令牌內省端點，或者采用了引用令牌的機制。
訪問令牌本質上是一個持有者憑證，誰拿到它誰就能用。把它的壽命拉得太長，等于把家門鑰匙配了一百把，然后漫不經心地灑在路面上。
在生產環境里，顯式設置生命周期不是可選項，而是必選項。你需要根據自己業務場景的實際風險承受能力來決定：一個移動端應用可能適合較長的刷新令牌生命周期，配合短期訪問令牌；而一個涉及資金操作的后臺管理系統，訪問令牌也許只需要幾分鐘的有效期就足夠了。不管你的答案是什么，第一步都是先把那個默認值換掉，換成你認真思考過、并且經過安全評審的數字。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
