(原)分布式用户认证方案汇总
前言
分布式用户认证,简单的称谓就是单点登陆,即一处登陆,到处通行。
说详细一点就是,集中式用户身份授权 + 分布式用户验证和资源访问。
看看国家的分布式用户认证是怎么运作的?
以美国为例,移民局负责颁发用户签证,而该国的大学、酒店、企业就是各种服务提供者。
这里用户认证和服务提供是分开的。
要入境美国,首先得向移民局申请签证。
当用户拿着签证去住酒店时,酒店服务员会查看签证的真伪及有效期。
当用户拿着签证去住企业应聘时,企业会查看签证的真伪及有效期,还有就是权限,如果是旅游签证,对不起,不能打工。
注意:签证是由移民局集中发行的,而校验却是分布的。
酒店服务员验证签证时,不会打电话到移民局查询真伪。
我们的用户认证系统,其实只要把这一套机制帮过来即可。
由统一的用户认证系统负责颁发签证(授权),而用户访问各种服务时,持有这个签证(验签)就可以了。
概念
中文 | 英文 | 含义 | 子类 |
---|---|---|---|
授权 | Authorization | 针对App | 让某App有权利访问某用户的信息 |
认证 | Authentication | 针对用户 | |
加密 | Encryption | 防偷窥,不被看到明文 | 对称、非对称 |
签名 | Signature | 防伪造 | |
令牌 | Token | 识别身份的依据 | 有状态、无状态 |
方案
父类 | 子类 | 解释 | 优点 | 缺点 | 适用 | 实现 |
---|---|---|---|---|---|---|
会话机制 | cookie-session | 安全问题CSRF,跨域问题 | BS结构 | |||
粘性session | 容器维护,将用户锁定到某一个服务器上 | 简单 | 缺乏容错性,服务器故障信息失效 | 发生故障对客户产生的影响较小;服务器发生故障是低概率事件 | Nginx | |
复制session | 容器维护,服务器同步session | 可容错 | 增加网络负荷 | 分布式环境 | tomcat集群广播 | |
共享session | 缓存维护,session和服务分离 | 可容错 | 复杂 | 分布式环境 | 分布式缓存 | |
持久化session | 数据库维护,session持久化 | 可容错 | 数据库造压力,难维护 | 分布式环境 | 数据库 | |
Token机制 | token | 安全问题XSS,空间占用大,无法作废 | CS结构 | |||
单一Token | ||||||
长短Token | ||||||
Json Web Token |
JWT介绍
基于JSON Web Token(JWT)的方案
JWT,简单的说就是把用户的公开信息和信息的签名合成一个字符串,保证信息无法伪造。
JWT和基于hash或随机值的普通token的主要不同点:- JWT 自身包含用户的公开信息。
- JWT 不用到中心服务器查询就可验证真伪。
这些特点,使得JWT很像现实生活中的身份证,签证等证件。
这个方案,通过用户登陆后,中心服务器给客户端一个JWT,这个JWT包含用户的公开信息,还有用户权限等信息。之后,客户端访问服务时,就以这个JWT作为身份识别,而服务提供者,不用到中心服务器查询,自己可校验这个JWT的真伪。
结论
- 简单来说,如果你的用户数据可能需要和第三方共享,或者允许第三方调用 API 接口,用Token。
- 在Web应用中,别再把JWT当做session使用,绝大多数情况下,传统的cookie-session机制工作得更好。
- JWT适合一次性的命令认证,颁发一个有效期极短的JWT,即使暴露了危险也很小,由于每次操作都会生成新的JWT,因此也没必要保存JWT,真正实现无状态。
参考
分布式环境下5种session处理策略
客户端与服务端Session那点秘密
一种全新的分布式用户认证架构设计
一种新的移动APP保持登陆的实现机制介绍
初步理解JWT并实践使用
讲真,别再使用JWT了!
为什么 APP 要用 token 而不用 session 认证?
10 Things You Should Know about Tokens
[认证授权] 2.OAuth2授权(续) & JWT(JSON Web Token)
https://jwt.io/