spring secutiry oauth2.0认证制授权

1.基本概念

1.1 什么是认证

进入移动互联网时代，大家每天都在刷手机，常用的软件有微信，支付宝，头条等，下面拿微信来举例子来说明认证相关的基本概念，在初次使用微信前需要注册成为微信用户，然后输入账号和密码即可登录微信，输入账号和密码登陆的过程就是认证。

系统为什么需要认证？

认证是为了保护系统隐私数据和资源，用户的身份合法方可访问该系统的资源。

认证：用户认证就是判断用户的身份是否合法的过程，用户去访问系统资源时系统要求验证用户的身份信息，身份合法方可继续访问，不合法则拒绝访问，常见的用户身份认证方式有：用户密码，二维码登录，手机短信登录，指纹认证等方式。

1.2什么是会话

用户认证通过后，为了避免用户的每次操作都进行认证可将用户的信息保证在会话中，会话就是系统为了保持当前用户登录状态所提供的机制，常见的有基于Session方式，基于token方式等

基于session的认证方式 如下图：

它的交互流程是，用户认证成功后，在服务端生成用户相关的数据保存在Session(当前会话)中，发给客户session id 存放在cookie中，这样用户客户端请求时带上session_id就可以验证服务器是否存在session数据，以此完成用户合法校验，当用户退出系统或Session过期销毁时，客户端的session_id也就失效了

基于token方式如下图：

它的交互流程是，用户认证成功后，服务端生成一个token发给客户端，客户端可以放到cookie或localstorge（现在浏览器存在的）等存储中，每次请求时带上token,服务端收到token通过验证后即可确认用户身份。  基于token方式的认证可以不记录在服务端。

1.2什么是授权

还拿微信来举例子，微信登录成功后用户即可以使用微信的功能，比如，发红包，发朋友圈，添加好友等，没有绑定银行卡的用户无法发送红包，绑定银行卡的用户才可以发红包，发红包的功能，发朋友圈的功能都是微信的即功能资源，用户拥有发红包的权限才可以正常使用发红包的功能，拥有发朋友圈的权限才可以使用发朋友圈的功能，这个根据用户的权限来控制用户使用资源的过程就是授权。

为什么需要授权？

认证是为了保证用户的合法性，授权则是为了更细粒度的对隐私数据进行划分，授权是在认证通过后发生的，控制不同的用户能够访问不同的资源。

授权：授权是用户认证通过根据用户的权限来控制用户访问资源的过程 ，拥有资源的访问权限则正常访问，没有权限则拒绝访问。

1.3授权的数据模型

如何进行授权即如可对用户访问资源进行控制，首先需要学习授权相关的数据模型

授权可简单的理解为who对what(which)进行how操作，包括以下内容：

who:即主体（subject）,主体一般是指用户，也可以是程序，需要访问的系统中的资源。

what:即资源（resource）,如系统菜单，页面，按钮，代码方法，系统商品信息，系统订单信息等，系统菜单，页面，按钮，代码方法都属于系统功能资源，对于Web页面每个功能通常对应一个url,系统商品信息，系统订单信息都属于实体资源（数据资源），实体资源由资源类型和资源实例组成，比如商品信息为资源类型，商品编号为0001的商品为资源实例。

how:权限、许可（premission）,规定了用户对资源的操作许可，权限离开了资源没有意义，如用户查询权限，用户添加权限，某个代码方法的调用权限，编号为001的用户的修改权限等，通过权限可知用户对哪些资源都有哪些操作许可。

主体、资源、权限关系如下图：

主体、资源、权限相关的数据模型如下：

主体（用户id，账号，密码、……）

资源（资源id,资源名称，访问地址、……）

权限（权限id,权限标识、权限名称、资源id、……）

角色（角色id,角色名称、……）

角色和权限关系（角色id,权限id,）

主体（用户）和角色的关系（用户id,角色id）

主体（用户）、资源、权限关系如下图

通常企业开发中将资源和权限表合并为一张权限表如下：

资源。（资源id,资源名称，访问地址……）

权限（权限id,权限标识，权限名称，资源id^）

合并为：

权限（权限id,权限标识，权限名称，资源名称，资源访问地址……）

修改后的数据模型之间的关系如下图

1.4RBAC

如何实现授权，业界通常基于rbac实现授权

1.4.1 基于角色的访问控制

RBAC基于角色的访问控制（Role-based access control）是按角色进行授权，比如：主体的角色为总经理，可以查询企业运营报表，查询员工工资信息等，访问控制流程如下

根据上图中的判断逻辑，授权代码可表示如下：

if(“主体”.hasRole("总经理角色id"))
{
    查询工资
}

如果上图中查询工资的所需要的角色为总经理和部门经理，此时就需要修改判断逻辑为“判断用户的角色是否是总经理或部门经理”，修改代码如下

if(“主体”.hasRole("总经理角色id") || "主体".hasrole("部门经理"))
{
    查询工资
}

根据上边的例子发现，当需要修改角色权限的时候就需要修改受权的相关代码，系统可扩展性差。

1.4.2基于资源的访问控制

RBAC基于资源的访问制制（resource-base access control）是按资源（或权限）进行授权，比如用户必须具有查询工资权限才可以查询员工工资信息等，访问控制如下

根据上图中的判断，授权代码可以表示为

if(主体.hasrole(“总经理角色id”)){
查询工资
}

优点，系统设计时定义好查询工资的权限标识，即体查询工资所需要的角钯变化为总经理和部门经理也不需要修改授权代码，系统扩展性强。