계통
- 이 뷰가 문서를 볼 무엇을 일정 기간에 기록 될 필요가 서버로 모든 요청은 새로운 HTTP 프로토콜이며, 이후 전 긴 시간, 웹 브라우징 요청에 대한 응답으로 추가됩니다 만 기본적으로 문서입니다 , 난 그냥 HTTP 요청을했다 했었던 기억하지 않습니다 특히 이후, 각 요청은 나를 위해 새로운 기능입니다. 이 시간은 매우 안녕하세요 피부입니다
- 그러나 온라인 쇼핑 사이트, 웹 사이트 등과 같은 대화 형 웹 애플리케이션의 상승으로 로그인해야하고, 즉시 문제에 직면, 그 장바구니로 이동하는 사람들을 기억해야 로그인 세션을 관리하는 것입니다. 나는 HTTP 요청이 무 상태이기 때문에,이 작은 도전하지, 모두를위한 공간을 분리, 그래서 방법을 마련해야, 상품을 넣어하는 세션 식별자 (세션 ID)를 보낼 수있는 모두를 제공하는 것입니다, 그것은 의미 임의의 문자열이, 각 사람이받는 다른, HTTP 요청이 받아이 문자열을 따라 함께 왔을 때 당신이 나에게 시작, 내가 구별 할 때마다 누가 사람입니다
- 그래서 아주 안녕하세요 피부가 있지만 서버가없는 가죽 이봐, 모든 사람들이 단지 세션 ID, 세션 ID와 모든 사람을 저장할 서버를 유지하기 위해 필요합니다! 수천의 경우 서버 등에 액세스하고 만든 수백, 수천의 수백.
이 심각 예를 들어, 나는 두 머신 클러스터를 형성 사용하여 서버의 확장 성을 제한, 거대한 서버 오버 헤드이라고합니다, F를 통해 작은 시스템 A가 시스템에 로그인 및 세션 ID가 가정, 시스템 A에 저장됩니다 어떻게 F는 작은 요청은 기계 B로 전달된다? 세션 ID 기계 B는 작은 F 아하지 않을 수 있습니다.
때로는 약간의 트릭을 사용 끈적 세션, F는 시스템 A에 부착 된 작은 요청을하는 것입니다, 그러나 이것은 효과가 없습니다, 그리고 시스템 A 끊지 경우, 이동 기계 B로 이동했다.
즉, 세션의 복사, 세션 ID가 빨리 소모 두 컴퓨터 사이에 주위를 이동했습니다.
나중에, 트릭의 Memcached가 지원이라는 사람 : 한 곳에서 중앙에 저장된 세션 ID는 모든 기계가이 곳의 데이터에 액세스하는 데 사용되는이 방법은, 그들은 복사하지 마십시오,하지만 경우, 단일 실패 지점의 가능성을 증가 세션은 기계를 끊었을 위해, 모든 사람들이 또 다시, 그것은 추정된다 MASI 사람들에 로그인했던 책임이있다.
또한이 기계를 넣어 단일 지점 클러스터 마련, 신뢰성을 높이기 위해 노력하지만 상관없이, 나를 위해이 작은 세션은 부담 것입니다
- 그래서 어떤 사람들은 내가이 불쾌한 세션을 저장하려는 이유에 대해 생각하고있다, 단지 각 클라이언트는 좋은 보존 내버려?
당신이 세션 ID를 저장하지 않는 경우에, 어떻게 우리 세대가 할됩니다 실제로 나에게 보낸 클라이언트의 세션 ID를 확인하려면? 당신이 확인하지 않으면, 우리는 그 사람들은 그들이 원하는 무엇이든, 악의적 인 세션 ID를 위조 할 수 있습니다, 그들은 합법적 인 사용자가 로그온하지 않은 것을 알고하지 않습니다.
아, 예, 중요한 점은 확인하는 것입니다!
예를 들어, 작은 F가 시스템에 로그인 한, 나는 그에게 제안 된 사용자 ID 작은 F, 내가 다시 HTTP 요청을 통해 작은 F를 방문 할 때를 포함하는 토큰 (토큰), 보낼 때와의 HTTP 헤더를 통해이 토큰 아니 그 이상.
그러나이 세션 ID와 아, 사람이 위조 할 수있는 중요한 차이가 없다, 그래서,에 대한 뭔가를해야 다른 사람이 가짜하지 할 수 있도록.
그런 다음 데이터가 서명, 예를 들어, 내가 알고리즘 HMAC-SHA256, 플러스 내가 키를 알고만을 확인하기 위해 다른 키를 모르기 때문에, 데이터, 서명, 서명 및 표시로 함께 데이터를 만들 토큰을 위조 할 수 없습니다.
내가 저장하지 않고이 토큰 때이 같은 HMAC-SHA256 알고리즘과 같은 키, 데이터가 서명하면 재 계산 사용하고 서명이 토큰 비교를 할 때 이상 나 F이 작은 토큰, 데이터 부분은 확실하게 위조 된 동일하지 않을 경우 만약 그렇다면, 나는 작은 F가 이상 기록하고 있으며, 사용자 ID 작은 F에 직접 취할 수 있다는 것을 알고, 내가 보낸 사람을 말할 것이다 : 죄송합니다, 인증.
Token 中的数据是明文保存的（虽然我会用Base64做下编码， 但那不是加密）， 还是可以被别人看到的， 所以我不能在其中保存像密码这样的敏感信息。
当然， 如果一个人的token 被别人偷走了， 那我也没办法， 我也会认为小偷就是合法用户， 这其实和一个人的session id 被别人偷走是一样的。
这样一来， 我就不保存session id 了， 我只是生成token , 然后验证token ， 我用我的CPU计算时间获取了我的session 存储空间 ！
解除了session id这个负担， 可以说是无事一身轻， 我的机器集群现在可以轻松地做水平扩展， 用户访问量增大， 直接加机器就行。 这种无状态的感觉实在是太好了！
Cookie
cookie 是一个非常具体的东西，指的就是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存储功能。
cookie由服务器生成，发送给浏览器，浏览器把cookie以 K-V 形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。
Session
session 从字面上讲，就是会话。这个就类似于你和一个人交谈，你怎么知道当前和你交谈的是张三而不是李四呢？对方肯定有某种特征（长相等）表明他就是张三。
session 也是类似的道理，服务器要知道当前发请求给自己的是谁。为了做这种区分，服务器就要给每个客户端分配不同的“身份标识”，然后客户端每次向服务器发请求的时候，都带上这个“身份标识”，服务器就知道这个请求来自于谁了。至于客户端怎么保存这个“身份标识”，可以有很多种方式，对于浏览器客户端，大家都默认采用 cookie 的方式。
服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全，可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。
cookie和session的区别
session是存储服务器端，cookie是存储在客户端，所以session的安全性比cookie高。
获取session里的信息是通过存放在会话cookie里的session id获取的。而session是存放在服务器的内存中里，所以session里的数据不断增加会造成服务器的负担，所以会把很重要的信息存储在session中，而把一些次要东西存储在客户端的cookie里。
cookie确切的说分为两大类：会话cookie和持久化cookie。
会话cookie是存放在客户端浏览器的内存中，他的生命周期和浏览器是一致的，当浏览器关闭会话cookie也就消失了
持久化cookie是存放在客户端硬盘中，持久化cookie的生命周期是我们在设置cookie时候设置的那个保存时间，session的信息是通过sessionid获取的，而sessionid是存放在会话cookie当中的，当浏览器关闭的时候会话cookie消失，所以sessionid也就消失了，但是session的信息还存在服务器端，只是查不到所谓的session但它并不是不存在。所以session在服务器关闭的时候，或者是sessio过期，又或者调用了invalidate()，再或者是session中的某一条数据消失调用session.removeAttribute()方法，session在通过调用session.getsession来创建的。
Token
在Web领域基于Token的身份验证随处可见。在大多数使用Web API的互联网公司中，tokens 是多用户下处理认证的最佳方式。
以下几点特性会让你在程序中使用基于Token的身份验证
- 无状态、可扩展
- 支持移动设备
- 跨程序调用
- 安全
那些使用基于Token的身份验证的大佬们
大部分你见到过的API和Web应用都使用tokens。例如Facebook, Twitter, Google+, GitHub等。
Token的起源
在介绍基于Token的身份验证的原理与优势之前，不妨先看看之前的认证都是怎么做的。
基于服务器的验证
我们都是知道HTTP协议是无状态的，这种无状态意味着程序需要验证每一次请求，从而辨别客户端的身份。
在这之前，程序都是通过在服务端存储的登录信息来辨别请求的。这种方式一般都是通过存储Session来完成。
随着Web，应用程序，已经移动端的兴起，这种验证的方式逐渐暴露出了问题。尤其是在可扩展性方面。
基于服务器验证方式暴露的一些问题
1.Seesion：每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。
2.可扩展性：在服务端的内存中使用Seesion存储登录信息，伴随而来的是可扩展性问题。
3.CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源，就可以会出现禁止请求的情况。
4.CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。
在这些问题中，可扩展行是最突出的。因此我们有必要去寻求一种更有行之有效的方法。
基于Token的验证原理
基于Token的身份验证是无状态的，我们不将用户信息存在服务器或Session中。
这种概念解决了在服务端存储信息时的许多问题
NoSession意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。
基于Token的身份验证的过程如下:
- 用户通过用户名和密码发送请求。
- 程序验证。
- 程序返回一个签名的token 给客户端。
- 客户端储存token,并且每次用于每次发送请求。
- 服务端验证token并返回数据。
每一次请求都需要token。token应该在HTTP的头部发送从而保证了Http请求无状态。我们同样通过设置服务器属性Access-Control-Allow-Origin:* ，让服务器能接受到来自所有域的请求。需要主要的是，在ACAO头部标明(designating)*时，不得带有像HTTP认证，客户端SSL证书和cookies的证书。
实现思路：
- 用户登录校验，校验成功后就返回Token给客户端。
- 客户端收到数据后保存在客户端
- 客户端每次访问API是携带Token到服务器端。
- 服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码
当我们在程序中认证了信息并取得token之后，我们便能通过这个Token做许多的事情。
我们甚至能基于创建一个基于权限的token传给第三方应用程序，这些第三方程序能够获取到我们的数据（当然只有在我们允许的特定的token）
Tokens的优势
无状态、可扩展
在客户端存储的Tokens是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载负载均衡器能够将用户信息从一个服务传到其他服务器上。
如果我们将已验证的用户的信息保存在Session中，则每次请求都需要用户向已验证的服务器发送验证信息(称为Session亲和性)。用户量大时，可能会造成
一些拥堵。
但是不要着急。使用tokens之后这些问题都迎刃而解，因为tokens自己hold住了用户的验证信息。
安全性
请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，让我们少了对session操作。
token是有时效的，一段时间之后用户需要重新验证。我们也不一定需要等到token自动失效，token有撤回的操作，通过token revocataion可以使一个特定的token或是一组有相同认证的token无效。
可扩展性
Tokens能够创建与其它程序共享权限的程序。例如，能将一个随便的社交帐号和自己的大号(Fackbook或是Twitter)联系起来。当通过服务登录Twitter(我们将这个过程Buffer)时，我们可以将这些Buffer附到Twitter的数据流上(we are allowing Buffer to post to our Twitter stream)。
使用tokens时，可以提供可选的权限给第三方应用程序。当用户想让另一个应用程序访问它们的数据，我们可以通过建立自己的API，得出特殊权限的tokens。
多平台跨域
我们提前先来谈论一下CORS(跨域资源共享)，对应用程序和服务进行扩展的时候，需要介入各种各种的设备和应用程序。
Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.
只要用户有一个通过了验证的token，数据和资源就能够在任何域上被请求到。
Access-Control-Allow-Origin: *
基于标准
创建token的时候，你可以设定一些选项。我们在后续的文章中会进行更加详尽的描述，但是标准的用法会在JSON Web Tokens体现。
最近的程序和文档是供给JSON Web Tokens的。它支持众多的语言。这意味在未来的使用中你可以真正的转换你的认证机制。