- 什么是认证
- 基于Session的认证方式
- 基于Token的认证方式
- 什么是授权
- 授权的数据模型
- RBAC实现授权
跳转到目录
- 进入移动互联网时代,大家每天都在刷手机,常用的软件有微信、支付宝、头条等,下边拿微信来举例子说明认证相关的基本概念,在初次使用微信前需要注册成为微信用户,然后输入账号和密码即可登录微信,
输入账号和密码登录微信的过程
就是认证
。 - 系统为什么要认证? 认证是为了保护系统的隐私数据与资源,用户的身份合法方可访问该系统的资源。
认证
:用户认证就是判断一个用户的身份是否合法的过程,用户去访问系统资源时系统要求验证用户的身份信息,身份合法方可继续访问,不合法则拒绝访问。常见的用户身份认证方式有:用户名密码登录
,二维码登录
,手机短信登录
,指纹认证
等方式。
- 用户认证通过后,为了
避免用户的每次操作都进行认证
可将用户的信息保证在会话
中。会话就是系统为了保持当前用户的登录状态所提供的机制,常见的有基于Session方式、基于Token方式
等
基于Session
的认证方式如下图 : 跳转到目录
重要: Session的认证流程
- 它的交互流程是,用户认证成功后,在服务端生成用户相关的数据保存在
session(当前会话)
中,发给客户端的 sesssion_id
存放到cookie
中,这样用户客户端请求时带上 session_id 就可以验证服务器端是否存在 session 数据,以此完成用户的合法校验,当用户退出系统或session过期销毁时,客户端的session_id也就无效了。基于
Token
方式如下图: 跳转到目录
重要: Token的认证流程
- 它的交互流程是,用户认证成功后,服务端生成一个
token(令牌)
发给客户端,客户端可以放到cookie
或localStorage
等存储中,每次请求时带上 token,服务端收到token通过验证后即可确认用户身份。
Session、Cookie和Token的主要区别
-
基于
Session
的认证方式由Servlet规范定制,服务端要存储session信息需要占用内存资源
,客户端需要支持 cookie; -
基于
token
的方式则一般不需要服务端存储token,并且不限制客户端的存储方式。如今移动互联网时代 更多类型的客户端需要接入系统,系统多是采用前后端分离的架构
进行实现,所以基于token的方式更适合
。
跳转到目录
根据用户的权限来控制用户使用资源的过程就是授权
微信来举例子,微信登录成功后用户即可使用微信的功能,比如,发红包、发朋友圈、添加好友等,没有绑定 银行卡的用户是无法发送红包的,绑定银行卡的用户才可以发红包,发红包功能、发朋友圈功能都是微信的资源即 功能资源
,用户拥有发红包功能的权限
才可以正常使用发送红包功能,拥有发朋友圈功能的权限才可以使用发朋友圈功能,这个根据用户的权限来控制用户使用资源的过程就是授权
。
为什么要授权?
-
认证是为了
保证用户身份的合法性
,授权则是为了更细粒度的对隐私数据进行划分
,授权是在认证通过后发生的, 控制不同的用户能够访问不同的资源。 -
授权 :
授权是用户认证通过根据用户的权限来控制用户访问资源的过程,拥有资源的访问权限则正常访问,没有权限则拒绝访问。
跳转到目录
如何进行授权
即如何对用户访问资源进行控制
,首先需要学习授权相关的数据模型
。
授权可简单理解为Who对What(which)进行How操作,包括如下: 哪些用户对哪些资源有哪些权限的操作
-
Who,即主体(Subject),主体一般是指
用户
,也可以是程序,需要访问系统中的资源。 -
What,即
资源
(Resource),如系统菜单、页面、按钮、代码方法、系统商品信息、系统订单信息等。系统菜单、页面、按 钮、代码方法
都属于系统功能资源
,对于web系统每个功能资源通常对应一个URL;系统商品信息、系统订单信息 都属于实体资源(数据资源)
,实体资源由资源类型和资源实例组成,比如商品信息为资源类型,商品编号 为001 的商品为资源实例。 -
How,
权限/许可
(Permission),规定了用户对资源的操作权限
,权限离开资源没有意义, 如用户查询权限、用户添加权限、某个代码方法的调用权限、编号为001的用户的修改权限等,通过权限可知用户 对哪些资源都有哪些操作许可。
用户(主体)、资源、权限
关系如下图:
用户(主体)、资源、权限相关的数据模型
如下:
- 用户(用户id、账号、密码、…)
- 资源(资源id、资源名称、访问地址、…)
- 权限(权限id、权限标识、权限名称、资源id、…)
- 角色(角色id、角色名称、…)
- 中间表
角色和权限(role-permission)
关系(角色id、权限id、…)用户和角色(user-role)
关系(用户id、角色id、…)
每个角色有不同的权限
,角色就是对权限的打包
;- 管理员角色, 有增删改查的权限
- 用户角色, 有查的权限
跳转到目录
如何实现授权?业界通常基于RBAC实现授权
。
角色
的访问权限
- RBAC基于 角色的访问控制(Role-Based Access Control) 是按
角色
进行授权,比如:用户的角色为总经理可以查询企业运营报表,查询员工工资信息等,访问控制流程如下:
资源
的访问权限 (重点
)
RBAC
基于 资源的访问控制()Resource-Based Access Control) 是按资源(或权限)
进行授权,比如:用户必须具有查询工资权限才可以查询员工工资信息等,访问控制流程如下: