常见的认证框架：Spring Security 和 shiro。 OAuth2.0 主要用于分布式系统的认证授权的协议。
1、基本概念
1.1、什么是认证
进入移动互联网时代，大家每天都在刷手机，常用的软件有微信、支付宝、头条等。下面那微信来举个栗子说明认证相关的基本概念，在初次使用微信钱需要注册成为微信用户，然后输入账号和密码即可登录微信，输入账号和密码登录微信的过程就是认证过程。
认证是为了保护系统的隐私数据与资源，用户的身份合法可访问该系统的资源。
认证：用户认证就是判断用户的身份是否合法的过程，用户去访问系统资源时需要验证用户的身份信息，身份合法方可继续访问，不合法则拒绝访问。常见的用户身份认证方式有：用户名密码登录，二维码登录，手机短信登录，指纹认证等方法。
1.2、什么事会话
用户认证通过后，为了避免用户的每次操作都进行认证可将用户的信息保证在会话中。会话就是系统为了保持当前用户的登录状态所提供的机制，常见的有基于session方式、基于token方式等。
1.2.1、基于session的认证方式
它的交互流程是，用户认证成功后，在服务端生成用户相关的数据保存在session(当前会话)中，发给客户端的sesssion_id存放到cookie中，这样用户客户端请求时带上session_id就可以验证服务器端是否存在session数据，以此完成用户的合法校验，当用户退出系统或session过期销毁时,客户端的session_id也就无效了。
1.2.2、基于token的认证方式
它的交互流程是，用户认证成功后，服务端生成一个token发给客户端，客户端可以放到cookie或者localStorage 等存储中，每次请求时带上token，服务端收到token通过验证后即可确认用户身份。
1.2.3、session和token方式的简单对比
基于session的认证方式有Servlet规范定制，服务端要存储session信息需要占用内存资源，客户端需要支持cookie；基于token的方式则一般不需要服务端存储token，并且不限制客户端的存储方式。
1.3、什么是授权
还是拿微信来举例子，微信登录成功后用户即可使用微信的功能，比如，发红包、发朋友圈、添加好友等，没有绑定银行卡的用户是无法发送红包的，绑定银行卡的用户才可以发红包，发红包功能、发朋友圈功能都是微信资源功能资源，用户拥有发红包的功能的权限才可以正常化使用发红包的功能，用户发朋友圈功能的权限才可以使用发朋友圈功能，这个根据用户的权限来控制用户使用资源的过程就是授权。
为什么要授权？
认证是为了保证用户身份的合法性，授权则是为了更细粒度的对隐私数据进行划分，授权是在认证通过后发生的，控制不同的用户能够访问不同的资源。
授权：授权是用户认证通过根据用户的权限来控制用户访问资源的过程，拥有资源的访问权限才可以正常访问，没有访问权限则拒绝访问。
1.4、授权的数据模型
如何进行授权即如何对用户访问资源进行控制，手下需要连接授权相关的数据模型
授权可简单理解对 谁(Who) 对 什么(what) 进行 怎么（how）样的操作，包括如下：
* **Who**即主体（Subject）,一般指用户，也可以是程序，需要访问系统中的资源。
* **What**即资源 （Resource），如系统菜单、页面、按钮、代码方法、系统商品信息、系统订单信息等。系统菜单、页面、按钮、代码方法都属于系统功能资源，对于web系统每个功能资源通常对应一个URL；系统商品信息、系统订单信息 都属于实体资源（数据资源），实体资源由资源类型和资源实例组成，比如商品信息为资源类型，商品编号 为001的商品为资源实例。
* **How**权限/许可（Permission），规定了用户对资源的操作许可，权限离开资源没有意义， 如用户查询权限、用户添加权限、某个代码方法的调用权限、编号为001的用户的修改权限等，通过权限可知用户对哪些资源都有哪些操作许可。
主体、资源、权限关系图：
- 主体、资源、权限相关的数据模型如下：
- 主体（用户id、账号、密码、...）
- 资源（资源id、资源名称、访问地址、...）
- 权限（权限id、权限标识、权限名称、资源id、...）
- 角色（角色id、角色名称、...）
- 角色和权限关系（角色id、权限id、...）
- 主体（用户）和角色关系（用户id、角色id、...）
主体、资源、权限关系图:
通常企业开发中将资源和权限表合并为一张权限表，如下：
- 资源（资源id、资源名称、访问地址、...）
- 权限（权限id、权限标识、权限名称、资源id、...）
合并为：
- 权限（权限id、权限标识、权限名称、资源名称、资源访问地址、...）
修改后数据模型之间的关系如下图****：
1.5、RBAC
如何实现授权？行业内通常基于RBAC实现授权。
1.5.1、基于角色的访问控制
RBAC 基于角色的访问控制（Role-Based Access Control）是按角色进行授权，比如主体的角色为总经理，可以查看企业运营报表，查询员工工资信息等。
访问控制流程图如下：
if(主体.hasRole("总经理角色id")|| 主体.hasRole("部门经理角色id")){
查询工资
}
根据上边的例子发现，当需要修改角色的权限的时候就需要修改授权的相关代码，系统可扩展性差。
1.5.2、基于资源的访问控制
RBAC 基于资源的访问控制（Resource-Based Access Control）是按资源（或权限）进行授权，比如：用户必须具有查询工资权限才可以查询员工工资信息等
访问控制流程如下：
if(主体.hasPermission("查询工资的权限标识")){
查询工资
}
优点：系统设计时定义好查询工资的权限标识，机试查询工资所需的角色变化为总经理和部门经理也不需要修改授权代码，系统可扩展性强。