在漫长的开发过程中，权限认证是一个永恒不变的话题，随着技术的发展，从以前的基于sessionId的方式，变为如今的token方式。session常用于单体应用，后来由于微服务的兴起，分布式应用占了很大的一部分。本文将为大家介绍基于session的单体应用授权认证方式。后续会介绍基于token的认证方式。
输入账号和密码登录的过程就是认证，看是否合法。认证是为了保护系统的隐私数据和资源。用户的身份合法才能访问该系统资源。
用户认证就是判断一个用户身份是否合法的过程，合法继续访问，不合法拒绝访问。
常见的用户认证方式有：用户密码登录，手机短信登录，指纹认证等。
用户认证通过后，为了避免用户的每次操作都进行认证，可以将用户的信息保存在会话中，会话就是为了保持当前用户的登录状态，提供的一种机制。
常见的有基于session方式、基于token方式。
用户认证成功后，在服务端生成用户相关的数据保存在session中，发给客户端的session_id存放到cookie中。用户客户端请求的时候带上session_id就可以验证服务器是否存在session数据，以此完成用户的合法校验。当用户退出系统或session过期销毁，客户端的session_id也就无效了。
用户认证成功后，服务端生成一个token发给客户端，客户端放到cookie或localstorage等存储中。每次请求时，带上token，服务端收到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、角色名称、...）
角色和权限关系（角色id、权限id、...）
主体（用户）和角色关系（用户id、角色id、...）
主体（用户）、资源、权限关系如下图：