认证授权——概念详解

认证(Authentication)和授权(Authorization)的区别是什么？

这两个单词长得很像，而且经常放在一起说。所以很多人可能以为是一件事。其实并不是。这是两个概念。简单点说；

认证(Authentication):你是谁
授权(Authorization):你有权限干什么

稍微正式一点的解释：

认证(Authentication):验证您的身份的凭据。通过这个凭据，系统知道你是谁。所以Authentication也被称为身份/用户验证。
授权(Authorization):授权是在认证之后，主要掌管我们访问系统的权限。

其实我们可以简单的理解成认证算是身份证。证明你是谁的一个过程。而授权可以理解成你这个人的权限，比如说你可以进自己家。你可以去你的单位上班。这些权限的前提是你是你。所以认证是前提，授权是基于认证之后的。
这两个我们一般都会结合使用，为了保证我们系统的安全性。

RBAC模型

系统权限控制最常采用的访问控制模型就是RBAC模型。
什么是RBAC呢？Role-Based Access Control。
RBAC即基于角色的权限访问控制。这是一种通过角色关联权限，角色同时又关联用户的授权方式。
打个比方，在中国警察这个角色可以带枪。而A是警察，我们从而知道A可以带枪。
其实A是用户，警察是角色，带枪是权限。额RBAC就是这种通过角色来关联用户和权限的。当然了用户和角色，角色和权限都是多对多的关系。
比如警察可以带枪，可以开警车，可以抓贼。
然后A可以是警察，B也可以是警察，C也可以是。
并且A除了是警察还可以是他孩子的父亲(可以抓贼，可以带孩子玩，可以辅导孩子写作业，还可以打孩子)，他妻子的老公(可以抓贼，可以亲妻子，可以和妻子拥抱，可以和妻子一起睡)。
由此可以看出，用户和角色，角色和权限都是多对多的关系。
上面的是理论，下面落到实际其实就是五张表的事(我直接借用现成的图了)：

用户-角色-权限表

三张表表分别是用户表，角色表，菜单表。两张关联表就形成了这个权限控制。
我们抽取共性创建一个角色并为之赋予对应的权限。然后把用户设置成这个权限就可以了。

什么是Cookie？Cookie的作用是什么？

其实说到Cookie就不得不提Session。都是用来跟踪浏览器用户身份的会话方式。但是两者的区别是Cookie存在客户端，Session存在服务端。

如何在项目中使用Cookie

所有的例子都是spring boot项目。
设置Cookie返回给客户端

@GetMapping("/change-username")
public String setCookie(HttpServletResponse response) {
    // 创建一个 cookie
    Cookie cookie = new Cookie("username", "Jovan");
    //设置 cookie过期时间
    cookie.setMaxAge(7 * 24 * 60 * 60); // expires in 7 days
    //添加到 response 中
    response.addCookie(cookie);

    return "Username is changed!";
}

使用spring框架提供的@CookieValue获取指定的Cookie的值

@GetMapping("/")
public String readCookie(@CookieValue(value = "username", defaultValue = "Atta") String username) {
    return "Hey! My username is " + username;
}

读取所有的Cookie值

@GetMapping("/all-cookies")
public String readAllCookies(HttpServletRequest request) {

    Cookie[] cookies = request.getCookies();
    if (cookies != null) {
        return Arrays.stream(cookies)
                .map(c -> c.getName() + "=" + c.getValue()).collect(Collectors.joining(", "));
    }

    return "No cookies";
}

如何使用Session-Cookie方案进行身份验证

上面说过了Cookie存在于客户端，Session存在于服务端。而实际上我们使用的时候是二者都用的。举个例子：

用户成功登录，服务器为用户创建一个Session，并将需要的信息存储起来(包括不限于用户名，用户角色，用户菜单权限，用户数据权限等)。
服务器返回给客户端一个SessionId。写入Cookie
当用户保存登录状态时，每次请求带上Cookie，Cookie里有SessionId
服务器获取SessionId与存储在内存或者数据库中的session进行比较，以验证用户的身份。返回给用户客户端响应信息的时候会附带用户当前的状态。

以上需要注意的有两点：

session的过期时间。
要确保客户端开启了Cookie。

多服务器节点下Session-Cookie方案如何做

在单体环境中Session-Cookie方案非常好实现，但是当服务器水平扩展成多节点，Session-Cookie方案就有挑战了。
比如说我们有A,B两个节点。用户登录请求了A，Session存在A服务器中。第二次请求B服务器，B中是没有Session信息的，就还需要用户登录。
其实这种情景有多种处理方式：

用hash算法确保一个用户的请求必然落在固定的服务器上。
这种做法一个节点宕机需要重新登录。
服务器之间的Session信息同步。
这种做法成本比较大，而且节点越多成本越高。
使用单独的服务器存储session。
比较常用的一种做法

如果没有Cookie的话Session还能用么

其实这个是可以的。Cookie是一个客户端存储的地方。如果不用Cookie的话，我们完全可以把这个id设置成消息头，或者说作为一个固定参数都可以。当然了这种方式安全性不是那么高。

为什么Cookie无法防止CSRF攻击，而Token可以？

CSRF是跨站请求伪造。什么是跨站请求伪造呢？就是用你的身份去发送一些不友好的请求。比如下面某个网上银行的帖子区有这么一个链接。当用户点击这个链接的时候会偷摸调用转账的请求。如下:

<a src=http://www.mybank.com/Transfer?bankId=11&money=10000>科学理财，年盈利率过万</>

注意Cookie中存着SessionId。而Cookie是存在浏览器中的。也就是说你在这个页面访问这个域名下的地址，都会自动把Cookie带上。所以你点击如上链接的时候，银行会以为你主动调用转账接口，从而实现转账(不要杠转账还需要输入密码啥的)

但是如果使用Token的话，登录成功获取token后，一般我们都会存在localStorage中。然后我们前端在请求中会做全局配置自动加上这个token。所以可以防止上面这种情况(因为这个链接没走前端的处理，不会加上token)

什么是Token？什么是JWT?

我们上面说了Session来鉴别用户的身份，也学会了基本的使用。但是其实这个需要客户端服务端都存储信息，而且依赖Cookie，不适合移动端。所以后来有了一种不需要自己存放Session信息就能实现身份验证的方式。
我们基于Token来做身份验证即可。我们这里说的AccessToken指的是访问资源接口(api)时所需要的凭证。比方说访问Github的一些api的时候，需要带上一个Token来表明你有访问权。
JWT(Json web Token)是目前最流行的跨域认证解决方案。是一种基于token 的认证授权机制。JWT本身也是token，不过是一种规范化之后的JSON结构的Token。

什么是SSO？

SSO(Single Sign On)即单点登录。说明用户登录多个子系统的其中一个就有权限访问与其相关的其它系统。这个我最近正好在做。比如说美团，我们登录美团以后，可以在首页点进美团外卖，美团打车，美团骑行等子系统。而之所以我们叫它们子系统是因为这些系统也有单独的门户。比如说美团外卖是一个单独的app。

什么是OAuth 2.0?

OAuth是一个行业的标准授权协议。主要是用来授权第三方应用获取有限的权限。
实际上它就是一种授权机制，最终目的是为第三方应用颁发一个有时效性的令牌token，使得第三方应用能够通过该令牌获取相关的资源。
OAuth比较常用的场景就是第三方登录。现在也比较常见于支付场景。

这篇笔记就记到这里吧，感觉好多概念都讲了，但是可能没讲的那么透，JWT和SSO我都打算单独整理。最近工作也在做SSO，所以掺杂了很多自己的理解和白话。如果有说的不准确的欢迎指出，之后我会试着整理一些落地的东西，稍微帮到你了记得点个喜欢点个关注。也祝大家工作顺顺利利！