认证： 就是对系统访问者的身份进行确认。 用户名密码登录、 二维码登录、手机短信登录、指纹、刷脸。。。
授权：就是对系统访问者的行为进行控制。授权通常是在认证之后，对系统内的用户隐私数据进行保护。后台接口访问权限、前台控件的访问权限。
RBAC模型： 主体 -》 角色 -》 资源 -》访问系统的行为。
认证和授权也是对一个权限认证框架进行扩展的两个主要的方面。
1、session保存在服务器，客户端不知道其中的信息；cookie保存在客户端，服务器能够知道其中的信息。
2、session中保存的是对象，cookie中保存的是字符串。
3、session不能区分路径，同一个用户在访问一个网站期间，所有的session在任何一个地方都可以访问到。而cookie中如果设置了路径参
数，那么同一个网站中不同路径下的cookie互相是访问不到的。
4、session需要借助cookie才能正常。如果客户端完全禁止cookie，session将失效。
1 .基于数据库的Session共享
2 .基于NFS共享文件系统
3 .基于memcached 的session，如何保证 memcached 本身的高可用性？
4 . 基于resin/tomcat web容器本身的session复制机制
5 . 基于TT/Redis 或 jbosscache 进行 session 共享。
6 . 基于cookie 进行session共享
当服务器tomcat第一次接收到客户端的请求时，会开辟一块独立的session空间，建立一个session对象，同时会生成一个session id，通过响应头的方式保存到客户端浏览器的cookie当中。以后客户端的每次请求，都会在请求头部带上这个session id，这样就可以对应上服务端的一些会话的相关信息，比如用户的登录状态。
如果没有客户端的Cookie，Session是无法进行身份验证的。
当服务端从单体应用升级为分布式之后，cookie+session这种机制要怎么扩展？
1、session黏贴： 在负载均衡中，通过一个机制保证同一个客户端的所有请求都会转发到同一个tomcat实例当中。问题： 当这个tomcat实例出现问题之后，请求就会被转发到其他实例，这时候用户的session信息就丢了。
2、session复制： 当一个tomcat实例上保存了session信息后，主动将session 复制到集群中的其他实例。问题： 复制是需要时间的，在复制过程中，容易产生session信息丢失。
3、session共享： 就是将服务端的session信息保存到一个第三方中，比如Redis。
CSRF： Cross Site Requst Forgery 跨站请求伪造
一个正常的请求会将合法用户的session id保存到浏览器的cookie。这时候，如果用户在浏览器中打来另一个tab页， 那这个tab页也是可以获得浏览器的cookie。黑客就可以利用这个cookie信息进行攻击。
攻击过程：
1、某银行网站A可以以GET请求的方式发起转账操作。 www.xxx.com/transfor.do?accountNum=100&money=1000 accountNum表示目标账户。这个请求肯定是需要登录才可以正常访问的。
2、攻击者在某个论坛或者网站上，上传一个图片，链接地址是 www.xxx.com/transfer.do?accountNum=888&money=10000 其中这个accountNum就是攻击者自己的银行账户。
3、如果有一个用户，登录了银行网站，然后又打开浏览器的另一个tab页，点击了这个图片。这时，银行就会受理到一个带了正确cookie的请求，就会完成转账。用户的钱就被盗了。
CSRF方式方式：
1、尽量使用POST请求，限制GET请求。POST请求可以带请求体，攻击者就不容易伪造出请求。
2、将cookie设置为HttpOnly : respose.setHeader(“Set-Cookie”,“cookiename=cookievalue;HttpOnly”)。
3、增加token；
在请求中放入一个攻击者无法伪造的信息，并且该信息不存在于cookie当中。
这也是Spring Security框架中采用的防范方式。