认证就是取得合法身份，比如京东需要用户登录以后才能才能下订单，这里的登录就是认证。登录成功以后就具有了合法身份可以继续进行下一步的操作。
网站建设哪家好，找创新互联建站！专注于网页设计、网站建设、微信开发、小程序设计、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了金口河免费建站欢迎大家使用！
常用的认证方式有基于session的认证和基于token的认证。
先来看一下基于session的认证：
用户登录成功后服务器会将用户的信息保存在session(当前会话)当中，每个session对应有一个sessionid,将该sessionid发送给客户端保存在cookie中。客户端下次访问的时候会将该sessioid带上，在服务器端进行比对看是否存在对应的session以此判断是否登录。
再来看基于token的验证：
用户登录成功后服务端生成一个token发送给客户端，客户端将收到的token存储在cookie或localstorage中，下次访问的时候带上token到服务端验证。
Session和token方式比较：
Sesion的认证方式需要将session存储在服务端，会占用服务端的内存，并且需要客户端开启cookie功能，而基于token的认证方式则不用将token存储在服务端，客户端的保存也比较灵活，现在前后端分离的开发方式越来越流行，所以采用基于token的验证方式更合适。
用户登录京东以后可以浏览商品，可以加入购物车，可以搜索商品，这些都是京东的功能，也是资源权限，我们说登录用户拥有这些权限，但是如果用户没有绑定银行卡就无法支付，那么没有绑定银行的的用户就不具有支付权限。给用户授予相应功能权限的过程就叫授权，只有授权以后用户才具有了相应的功能权限。
认证的过程是识别用户身份是否合法，而授权是给予已经通过认证的用户功能权限的过程,授权是在认证之后发生的.
RBAC是基于角色的权限控制，在RBAC里面有三大要素用户、角色和权限：
用户：用户是权限管理的主体，用户使用系统。
角色：如果给每个用户单独的分配权限会很繁琐，比如多个用户重复分配同一权限，引入角色的概念就会让权限管理更为灵活，我们可以设置多个用户为同一角色，然后给角色分配权限，则该角色下的用户就都拥有了同样的权限，比如：张老师，王老师，李老师都分配老师的角色，给老师分配查询学生信息的权限则所有的老师都拥有了查询学生信息的权限。一个用户也可以分配多个角色，比如：张老师可以既是老师又是学术经理，那么他就同时具备了老师和学术经理的权限。
权限：权限可以分为三类：
数据权限：也就是用户可以看到的数据内容，比如学校管理系统，老师只能看到学生的数据，学术经理可以看到学生和老师的数据。
页面权限：这个部分的权限属于基本的权限范畴，一般系统都会有这个类型的权限，他可以限制用户能访问哪些页面，比如老师可以访问添加作业的页面，不能访问查询其他老师工资的页面，页面权限一般对应的是url地址。
操作权限：控制页面上的按钮，比如添加，修改，删除。
用户和角色是多对多的关系，角色和权限也是多对多的关系。
RBAC的权限控制系统通常对应五张表，举例说明：
用户表：
序号 | 字段名称 | 字段类型 | 字段描述 |
1 | id | varchar2 | 无意义，主键uuid |
2 | varchar2 | 非空，唯一 | |
3 | username | varchar2 | 用户名 |
5 | password | varchar2 | 密码（加密） |
6 | phoneNum | varchar2 | 电话 |
7 | status | int | 状态0未开启1开启 |
角色表：
序号 | 字段名称 | 字段类型 | 字段描述 |
1 | id | varchar2 | 无意义，主键uuid |
2 | roleName | varchar2 | 角色名 |
3 | roleDesc | varchar2 | 角色描述 |
权限表：
序号 | 字段名称 | 字段类型 | 字段描述 |
1 | id | varchar2 | 无意义，主键uuid |
2 | permissionName | varchar2 | 权限名 |
3 | url | varchar2 | 资源路径 |
用户角色关系表：
序号 | 字段名称 | 字段类型 | 字段描述 |
1 | userId | varchar2 | 用户id(外键) |
2 | roleId | varchar2 | 角色id(外键) |
角色权限关系表：
序号 | 字段名称 | 字段类型 | 字段描述 |
1 | permissionId | varchar2 | 权限id(外键) |
2 | roleId | varchar2 | 角色id(外键) |
