首页  思维导图  详情

认证授权Cookie\JWTOauth

2022-03-16 21:24:32   18  举报





AI智能生成

认证授权

作者其他创作

大纲/内容

认证 (Authentication) 和授权 (Authorization)的区别

Authentication（认证）是验证您的身份的凭据（例如用户名/用户ID和密码），通过这个凭据，系统得以知道你就是你，也就是说系统存在你这个用户。所以，Authentication 被称为身份/用户验证。

Authorization（授权）发生在 Authentication（认证）之后。授权嘛，光看意思大家应该就明白，它主要掌管我们访问系统的权限。比如有些特定资源只能具有特定权限的人才能访问比如admin，有些对系统资源操作比如删除、添加、更新只能特定人才具有。

这两个一般在我们的系统中被结合在一起使用，目的就是为了保护我们系统的安全性。

Cookie\Session

定义

维基百科是这样定义 Cookie 的：Cookies是某些网站为了辨别用户身份而储存在用户本地终端上的数据（通常经过加密）。简单来说： Cookie 存放在客户端，一般用来保存用户信息。

应用案例

1.我们在 Cookie 中保存已经登录过的用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了。除此之外，Cookie 还能保存用户首选项，主题和其他设置信息。
2.使用Cookie 保存 session 或者 token ，向后端发送请求的时候带上 Cookie，这样后端就能取到session或者token了。这样就能记录用户当前的状态了，因为 HTTP 协议是无状态的。
3.Cookie 还可以用来记录和分析用户行为。举个简单的例子你在网上购物的时候，因为HTTP协议是没有状态的，如果服务器想要获取你在某个页面的停留状态或者看了哪些商品，一种常用的实现方式就是将这些信息存放在Cookie

session

定义

Session是存在服务器的一种用来存放用户数据的类HashTable结构。

通过服务端记录用户的状态

Session进行身份验证

通过 SessionID 来实现特定的用户，SessionID 一般会选择存放在 Redis 中。举个例子：用户成功登陆系统，然后返回给客户端具有 SessionID 的 Cookie，当用户向后端发起请求的时候会把 SessionID 带上，这样后端就知道你的身份状态了

1.用户向服务器发送用户名和密码用于登陆系统。

2.服务器验证通过后，服务器为用户创建一个 Session，并将 Session信息存储起来。

3.服务器向用户返回一个 SessionID，写入用户的 Cookie。

4.当用户保持登录状态时，Cookie 将与每个后续请求一起被发送出去。

5.服务器可以将存储在 Cookie 上的 Session ID 与存储在内存中或者数据库中的 Session 信息进行比较，以验证用户的身份，返回给用户客户端响应信息的时候会附带用户当前的状态。

注意事项

依赖Session的关键业务一定要确保客户端开启了Cookie。

注意Session的过期时间

区别

Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。相对来说 Session 安全性更高。如果使用 Cookie 的一些敏感信息不要写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密

思考

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

一般是通过 Cookie 来保存 SessionID ，假如你使用了 Cookie 保存 SessionID的方案的话，如果客户端禁用了Cookie，那么Seesion就无法正常工作。
但是，并不是没有 Cookie 之后就不能用 Session 了，比如你可以将SessionID放在请求的 url 里面https://javaguide.cn/?session_id=xxx 。这种方案的话可行，但是安全性和用户体验感降低。当然，为了你也可以对 SessionID 进行一次加密之后再传入后端。

Cookie 无法防止CSRF攻击，而token可以

CSRF（Cross Site Request Forgery）一般被翻译为跨站请求伪造

Session 认证中 Cookie 中的 SessionId是由浏览器发送到服务端的，借助这个特性，攻击者就可以通过让用户误点攻击链接，达到攻击效果。
但是，我们使用 token 的话就不会存在这个问题，在我们登录成功获得 token 之后，一般会选择存放在 local storage 中。然后我们在前端通过某些方式会给每个发到后端的请求加上这个 token,这样就不会出现 CSRF 漏洞的问题。因为，即使有个你点击了非法链接发送了请求到服务端，这个非法请求是不会携带 token 的，所以这个请求将是非法的。

Cookie 还是 token 都无法避免跨站脚本攻击（Cross Site Scripting）XSS

Storage

localStorage

用来作为本地存储来使用的，解决了cookie存储空间不足的问题(cookie中每条cookie的存储空间为4k)，localStorage中一般浏览器支持的是5M大小

永久性存储

sessionStorage

用于临时保存同一窗口(或标签页)的数据，在关闭窗口或标签页之后将会删除这些数据。

Token\JWT

JSON Web Token

一个开放的行业标准（RFC 7519），它定义了一种紧凑且独立的方式，用于在各方之间作为JSON对象安全地传输信息。此信息可以通过数字签名进行验证和信任。JWT可以使用秘密（使用HMAC算法）或使用RSA或ECDSA的公钥/私钥对进行签名，防止被篡改。

构成

头部Header、有效载荷Payload、签名Signature

1.头部：包含令牌的类型（JWT）与加密的签名算法（（如 SHA256 或 ES256），Base64编码后加入第一部分
2.有效载荷：通俗一点讲就是token中需要携带的信息都将存于此部分，比如：用户id、权限标识等信息。
注：该部分信息任何人都可以读出来，所以添加的信息需要加密才会保证信息的安全性
3.签名：用于防止 JWT 内容被篡改, 会将头部和有效载荷分别进行 Base64编码，编码后用 . 连接组成新的字符串，然后再使用头部声明的签名算法进行签名。在具有秘钥的情况下，可以验证JWT的准确性，是否被篡改。

优缺点

优点

1. JWT 基于 json，非常方便解析。
2. 可以在令牌中自定义丰富的内容，易扩展。
3. 通过非对称加密算法及数字签名技术，JWT 防止篡改，安全性高。
4. 资源服务器使用 JWT 可以不依赖认证服务器，即可完成授权

缺点

1.JWT令牌较长，占存储空间比较大，但是用户信息是有限的，所以在可接受范围。

流程

1.用户向服务器发送用户名和密码用于登陆系统。
2.身份验证服务响应并返回了签名的 JWT，上面包含了用户是谁的内容。
3.用户以后每次向后端发请求都在Header中带上 JWT。
4.服务端检查 JWT 并从中获取用户相关信息。

OAuth 2.0

定义

OAuth 2.0 是目前最流行的授权机制，用来授权第三方应用，获取用户数据。

OAuth 协议为用户资源的授权提供了一个安全的、开放而又简易的规范标准。与以往的授权方式不同之处是
OAuth 的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就
可以申请获得该用户资源的授权，因此 OAuth 是开放的安全的。

解决问题

1. 提供账号和密码给第三方应用程序后，应用可以访问用户在微信上的所有数据（有什么群，好友）
2. 用户只有修改密码后，才收回权限。但是如果一样将用户名和密码授权给了其他第三方应用，当你修改密码后，那么所有第三方应用程序都会被收回权限。
3. 密码泄露的可能性大大提高。因为无法控制接入应用对用户数据保护的安全系数，只要有一个接入的第三方应用遭到破解，那么用户的密码就会泄露，意味着用户的信息全部会被泄露，后果不堪设想。

OAuth 协议规范了授权方式，不采用授权帐号和密码的方式，而是使用令牌方式（Token）来解决授权问题，应用通过令牌去获取被授权的用户信息，从而可以避免上面存在的安全问题。

涉及角色

资源所有者（Resource Owner）

通常为 "用户"（user），如昵称、头像等这些资源的拥有者（用户只是将这些资源放到了服务提供商的资源服务器中）。

第三方应用（Third-party application）

又称为客户端（Client），比如官网想要使用微信的资源（昵称、头像等），官网对于QQ、微信等系统来说是第三者，我们称梦学谷官网为第三方应用。

认证服务器（Authorization server)

专门用来对资源所有者的身份进行认证、对要访问的资源进行授权、产生令牌的服务器。想访问资源，需要通过认证服务器由资源所有者授权后才可访问。

资源服务器（Resource server）

存储用户的资源（昵称、头像等）、验证令牌有效性。比如: 微信的资源服务器存储了微信的用户信息，淘宝的资源服务器存储了淘宝的用户信息等。注意：认证服务器和资源服务器虽然是两个解决，但其实他们可以是同一台服务器、同一个应用。

服务提供商（Service Provider）

如 QQ、微信等（包含认证和资源服务器）