作為B端產(chǎn)品經(jīng)理，我們每天都在設(shè)計用戶流程和權(quán)限體系。當開發(fā)同學提到“Session”、“Token”、“OAuth”這些詞時，你是否曾感覺一頭霧水，卻又不好意思深問？——其實，鑒權(quán)根本不是技術(shù)同學的“黑話”，而是產(chǎn)品經(jīng)理設(shè)計功能時必須掌握的底層業(yè)務(wù)邏輯。今天，我們就用最通俗的語言，拆解這份產(chǎn)品經(jīng)理專屬的鑒權(quán)知識手冊。

這絕非技術(shù)細節(jié)，而是關(guān)乎產(chǎn)品安全、體驗和商業(yè)模式的核心問題。

拋開技術(shù)術(shù)語，你可以把整套鑒權(quán)機制想象成公司的門禁系統(tǒng)：

目前主流有三種方案，它們各有優(yōu)劣，適用于不同的產(chǎn)品階段和場景。

這種模式很像傳統(tǒng)公司的前臺接待。用戶登錄（在前臺登記），服務(wù)器（前臺）會建立一個檔案（Session），并給你一張寫有編號的訪客貼（Session ID）。之后你在這棟樓里（網(wǎng)站內(nèi)）活動，每次進入新的房間（訪問新的頁面）都要出示這個貼紙，服務(wù)器（前臺）會根據(jù)編號核對你的檔案，確認你有權(quán)進入。

它的優(yōu)點是控制力強，服務(wù)器可以隨時讓某張訪客貼失效。缺點則是用戶量巨大時，服務(wù)器需要建立和管理海量的檔案，壓力很大；而且在多臺服務(wù)器（分公司）之間同步這些檔案信息也非常麻煩。

產(chǎn)品經(jīng)理選它 when：適用于用戶量不大、架構(gòu)簡單的傳統(tǒng)企業(yè)內(nèi)部管理系統(tǒng)。

第二種：Token方案 —— “自檢式演唱會門票”

這是當前最主流的方案。用戶登錄后，會收到一張加密的、內(nèi)含自身信息的“電子門票”（Token）。之后每次請求，客戶端都會主動出示這張門票。服務(wù)器的工作變得很簡單：只要驗票（檢查門票的防偽和有效期），而無需在本地記錄用戶狀態(tài)。

它的巨大優(yōu)勢是擴展性極佳，非常適合多服務(wù)器、微服務(wù)的現(xiàn)代架構(gòu)，也天然適配App。門票里可以直接寫明用戶的角色和權(quán)限，效率很高。它的一個小缺點是，門票一旦簽發(fā)，服務(wù)器無法中途單方面作廢，只能等它自然過期。

產(chǎn)品經(jīng)理選它 when：幾乎所有現(xiàn)代SaaS產(chǎn)品、前后端分離項目以及需要與第三方集成的系統(tǒng)，都應優(yōu)先考慮此方案。

第三種：Cookie方案 —— “公司門禁卡”

在這種模式下，用戶登錄后，服務(wù)器會通知瀏覽器發(fā)一張“門禁卡”（Cookie）。之后，瀏覽器每次訪問相關(guān)頁面都會自動、無聲地帶上這張卡。

它的優(yōu)點是用戶體驗無縫，用戶完全無感知。但缺點也很明顯：首先是跨域問題，在A域名下辦的門禁卡，無法用來刷開B域名的大門；它有一些固有的安全風險（如CSRF跨站請求偽造），需要額外手段來防護。

產(chǎn)品經(jīng)理選它 when：主要用于傳統(tǒng)且單一域名的Web網(wǎng)站。

懂了原理，關(guān)鍵在于應用。產(chǎn)品經(jīng)理最常面臨的鑒權(quán)決策，就是如何平衡安全與體驗。

核心矛盾：Token或會話的有效期設(shè)多長？

產(chǎn)品策略：實施分級安全策略。

在產(chǎn)品設(shè)計中，我們經(jīng)常需要讓用戶從A系統(tǒng)安全地訪問B系統(tǒng)的資源。這時，最優(yōu)雅的方案是OAuth 2.0協(xié)議，你可以理解為“授權(quán)代辦”模式。

生活化比喻：用微信登錄小程序

在你的項目中的應用：當設(shè)計系統(tǒng)A要調(diào)用系統(tǒng)C的資源時，可以讓系統(tǒng)B扮演“微信”的角色，負責鑒權(quán)和發(fā)放臨時通行證。這樣，系統(tǒng)A無需知道系統(tǒng)C的密碼，用戶也無需在系統(tǒng)A上重復登錄，既安全又便捷。

最后，請在評審或設(shè)計任何涉及權(quán)限的功能時，用這份清單拷問自己的設(shè)計：

對產(chǎn)品經(jīng)理而言，鑒權(quán)不是枯燥的技術(shù)實現(xiàn)，而是一套關(guān)于身份、信任與權(quán)限的業(yè)務(wù)規(guī)則。掌握它，你才能設(shè)計出既安全可靠、又體驗流暢的專業(yè)產(chǎn)品。