![]()
作為B端產品經理,我們每天都在設計用戶流程和權限體系。當開發同學提到“Session”、“Token”、“OAuth”這些詞時,你是否曾感覺一頭霧水,卻又不好意思深問?——其實,鑒權根本不是技術同學的“黑話”,而是產品經理設計功能時必須掌握的底層業務邏輯。今天,我們就用最通俗的語言,拆解這份產品經理專屬的鑒權知識手冊。
這絕非技術細節,而是關乎產品安全、體驗和商業模式的核心問題。
拋開技術術語,你可以把整套鑒權機制想象成公司的門禁系統:
目前主流有三種方案,它們各有優劣,適用于不同的產品階段和場景。
這種模式很像傳統公司的前臺接待。用戶登錄(在前臺登記),服務器(前臺)會建立一個檔案(Session),并給你一張寫有編號的訪客貼(Session ID)。之后你在這棟樓里(網站內)活動,每次進入新的房間(訪問新的頁面)都要出示這個貼紙,服務器(前臺)會根據編號核對你的檔案,確認你有權進入。
它的優點是控制力強,服務器可以隨時讓某張訪客貼失效。缺點則是用戶量巨大時,服務器需要建立和管理海量的檔案,壓力很大;而且在多臺服務器(分公司)之間同步這些檔案信息也非常麻煩。
產品經理選它 when:適用于用戶量不大、架構簡單的傳統企業內部管理系統。
第二種:Token方案 —— “自檢式演唱會門票”
這是當前最主流的方案。用戶登錄后,會收到一張加密的、內含自身信息的“電子門票”(Token)。之后每次請求,客戶端都會主動出示這張門票。服務器的工作變得很簡單:只要驗票(檢查門票的防偽和有效期),而無需在本地記錄用戶狀態。
它的巨大優勢是擴展性極佳,非常適合多服務器、微服務的現代架構,也天然適配App。門票里可以直接寫明用戶的角色和權限,效率很高。它的一個小缺點是,門票一旦簽發,服務器無法中途單方面作廢,只能等它自然過期。
產品經理選它 when:幾乎所有現代SaaS產品、前后端分離項目以及需要與第三方集成的系統,都應優先考慮此方案。
第三種:Cookie方案 —— “公司門禁卡”
在這種模式下,用戶登錄后,服務器會通知瀏覽器發一張“門禁卡”(Cookie)。之后,瀏覽器每次訪問相關頁面都會自動、無聲地帶上這張卡。
它的優點是用戶體驗無縫,用戶完全無感知。但缺點也很明顯:首先是跨域問題,在A域名下辦的門禁卡,無法用來刷開B域名的大門;它有一些固有的安全風險(如CSRF跨站請求偽造),需要額外手段來防護。
產品經理選它 when:主要用于傳統且單一域名的Web網站。
懂了原理,關鍵在于應用。產品經理最常面臨的鑒權決策,就是如何平衡安全與體驗。
核心矛盾:Token或會話的有效期設多長?
產品策略:實施分級安全策略。
在產品設計中,我們經常需要讓用戶從A系統安全地訪問B系統的資源。這時,最優雅的方案是OAuth 2.0協議,你可以理解為“授權代辦”模式。
生活化比喻:用微信登錄小程序
在你的項目中的應用:當設計系統A要調用系統C的資源時,可以讓系統B扮演“微信”的角色,負責鑒權和發放臨時通行證。這樣,系統A無需知道系統C的密碼,用戶也無需在系統A上重復登錄,既安全又便捷。
最后,請在評審或設計任何涉及權限的功能時,用這份清單拷問自己的設計:
對產品經理而言,鑒權不是枯燥的技術實現,而是一套關于身份、信任與權限的業務規則。掌握它,你才能設計出既安全可靠、又體驗流暢的專業產品。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
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.