![]()
作为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.