Token登陆认证知识

1. Cookie和seesion

定义:

指某些网站为了辨别用户身份而储存在用户本地终端(Client Side)上的数据(通常经过加密)。

用途:

由于HTTP是一种无状态的协议,服务器单从网络连接上无从知道客户身份。Cookie 一个典型的应用是当登录一个网站时,网站往往会请求用户输入用户名和密码,并且用户可以勾选“下次自动登录”。如果勾选了,那么下次访问同一网站时,用户会发现没输入用户名和密码就已经登录了。这正是因为前一次登录时,服务器发送了包含登录凭据(用户名加密码的某种加密形式)的 Cookie 到用户的硬盘上。第二次登录时,如果该 Cookie 尚未到期,浏览器会发送该 Cookie,服务器验证凭据,于是不必输入用户名和密码就让用户登录了。

保存时间:

cookie的保存时间,可以自己在程序中设置。如果没有设置保存时间,应该是一关闭浏览器,cookie就自动消失。

缺点:

  • Cookie 会被附加在每个 HTTP 请求中,所以无形中增加了流量。
  • 由于 HTTP 请求中的 Cookie 是明文传递的,所以安全性成问题,除非使用超文本传输安全协定。
  • Cookie 的大小限制在 4 KB 左右,对于复杂的存储需求来说是不够用的。

1.2 session

Session是另一种记录客户状态的机制,不同的是Cookie保存在客户端浏览器中,而Session保存在服务器上。客户端浏览器访问服务器的时候,服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话,那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。

session 也是类似的道理,服务器要知道当前发请求给自己的是谁。为了做这种区分,服务器就要给每个客户端分配不同的“身份标识”,然后客户端每次向服务器发请求的时候,都带上这个“身份标识”,服务器就知道这个请求来自于谁了。对于浏览器客户端,大家都默认采用 cookie 的方式,保存这个“身份标识”。

服务器使用session把用户的信息临时保存在了服务器上,用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全。

缺陷:

如果web服务器做了负载均衡,那么下一个操作请求到了另一台服务器的时候session会丢失。

提示:Session的使用比Cookie方便,但是过多的Session存储在服务器内存中,会对服务器造成压力。

1.3 客户端访问服务器流程

  • 首先,客户端会发送一个http请求到服务器端。
  • 服务器端接受客户端请求后,建立一个session,并发送一个http响应到客户端,这个响应头,其中就包含Set-Cookie头部。该头部包含了sessionId。Set-Cookie格式如下,Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]
  • 在客户端发起的第二次请求,假如服务器给了set-Cookie,浏览器会自动在请求头中添加cookie
  • 服务器接收请求,分解cookie,验证信息,核对成功后返回response给客户端
    Token登陆认证知识

2.基于token的验证方式

token验证的特点

  • 无状态、可扩展
  • 支持移动设备
  • 跨程序调用
  • 安全

2.1 token之前的认证

基于服务器的认证

我们都是知道HTTP协议是无状态的,这种无状态意味着程序需要验证每一次请求,从而辨别客户端的身份。
在这之前,程序都是通过在服务端存储的登录信息来辨别请求的。这种方式一般都是通过存储Session来完成。

基于服务器认证的弊端

基于服务器验证方式暴露的一些问题
1.Seesion:每次认证用户发起请求时,服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时,内存的开销也会不断增加。
2.可扩展性:在服务端的内存中使用Seesion存储登录信息,伴随而来的是可扩展性问题。
3.CORS(跨域资源共享):当我们需要让数据跨多台移动设备上使用时,跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源,就可以会出现禁止请求的情况。
4.CSRF(跨站请求伪造):用户在访问银行网站时,他们很容易受到跨站请求伪造的攻击,并且能够被利用其访问其他的网站。

2.2 基于Token的验证原理

基于Token的身份验证是无状态的,我们不将用户信息存在服务器中。这种概念解决了在服务端存储信息时的许多问题。NoSession意味着你的程序可以根据需要去增减机器,而不用去担心用户是否登录。

2.3 基于Token的身份验证的过程如下:

  1. 用户通过用户名和密码发送请求。
  2. 服务器端程序验证。
  3. 服务器端程序返回一个带签名的token 给客户端。
  4. 客户端储存token,并且每次访问API都携带Token到服务器端的。
  5. 服务端验证token,校验成功则返回请求数据,校验失败则返回错误码。
    Token登陆认证知识

2.4 Token的优势

  • 无状态、可扩展
    在客户端存储的Tokens是无状态的,并且能够被扩展。基于这种无状态和不存储Session信息,负载负载均衡器能够将用户信息从一个服务传到其他服务器上。tokens自己hold住了用户的验证信息。
  • 安全性
    请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token,cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中,让我们少了对session操作。
    token是有时效的,一段时间之后用户需要重新验证。
  • 可扩展性
    Tokens能够创建与其它程序共享权限的程序。
  • 多平台跨域

参考博文

  1. https://mp.weixin.qq.com/s/93FzBigxugfRKI5qN76mWA
  2. https://segmentfault.com/a/1190000017831088
  3. https://zh.wikipedia.org/wiki/Cookie#用途

Token登陆认证知识

上一篇:二分查找,折半查找,特殊情况二分查找


下一篇:EF-数据迁移、删除以及分页查询显示