共计 2216 个字符，预计需要花费 6 分钟才能阅读完成。
在简单理解 cookie/session 机制这篇文章中，简要阐述了 cookie 和 session 的原理。本文将要简单阐述另一个同 cookie/session 同样重要的技术术语：token。
什么是 token
token 的意思是令牌，是服务端生成的一串字符串，作为客户端进行请求的一个标识。
当用户第一次登录后，服务器生成一个 token 并将此 token 返回给客户端，以后客户端只需带上这个 token 前来请求数据即可，无需再次带上用户名和密码。
简单 token 的组成；uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign（签名，token 的前几位以哈希算法压缩成的一定长度的十六进制字符串。为防止 token 泄露）。
身份认证概述
由于 HTTP 是一种没有状态的协议，它并不知道是谁访问了我们的应用。这里把用户看成是客户端，客户端使用用户名还有密码通过了身份验证，不过下次这个客户端再发送请求时候，还得再验证一下。
通用的解决方法就是，当用户请求登录的时候，如果没有问题，在服务端生成一条记录，在这个记录里可以说明登录的用户是谁，然后把这条记录的 id 发送给客户端，客户端收到以后把这个 id 存储在 cookie 里，下次该用户再次向服务端发送请求的时候，可以带上这个 cookie，这样服务端会验证一下 cookie 里的信息，看能不能在服务端这里找到对应的记录，如果可以，说明用户已经通过了身份验证，就把用户请求的数据返回给客户端。
以上所描述的过程就是利用 session，那个 id 值就是 sessionid。我们需要在服务端存储为用户生成的 session，这些 session 会存储在内存，磁盘，或者数据库。
基于 token 机制的身份认证
使用 token 机制的身份验证方法，在服务器端不需要存储用户的登录记录。大概的流程：
客户端使用用户名和密码请求登录。服务端收到请求，验证用户名和密码。验证成功后，服务端会生成一个 token，然后把这个 token 发送给客户端。客户端收到 token 后把它存储起来，可以放在 cookie 或者 Local Storage（本地存储）里。客户端每次向服务端发送请求的时候都需要带上服务端发给的 token。服务端收到请求，然后去验证客户端请求里面带着 token，如果验证成功，就向客户端返回请求的数据。
利用 token 机制进行登录认证，可以有以下方式：
a. 用设备 mac 地址作为 token
客户端：客户端在登录时获取设备的 mac 地址，将其作为参数传递到服务端
服务端：服务端接收到该参数后，便用一个变量来接收，同时将其作为 token 保存在数据库，并将该 token 设置到 session 中。客户端每次请求的时候都要统一拦截，将客户端传递的 token 和服务器端 session 中的 token 进行对比，相同则登录成功，不同则拒绝。
此方式客户端和服务端统一了唯一的标识，并且保证每一个设备拥有唯一的标识。缺点是服务器端需要保存 mac 地址；优点是客户端无需重新登录，只要登录一次以后一直可以使用，对于超时的问题由服务端进行处理。
b. 用 sessionid 作为 token
客户端：客户端携带用户名和密码登录
服务端：接收到用户名和密码后进行校验，正确就将本地获取的 sessionid 作为 token 返回给客户端，客户端以后只需带上请求的数据即可。
此方式的优点是方便，不用存储数据，缺点就是当 session 过期时，客户端必须重新登录才能请求数据。
当然，对于一些保密性较高的应用，可以采取两种方式结合的方式，将设备 mac 地址与用户名密码同时作为 token 进行认证。
APP 利用 token 机制进行身份认证
用户在登录 APP 时，APP 端会发送加密的用户名和密码到服务器，服务器验证用户名和密码，如果验证成功，就会生成相应位数的字符产作为 token 存储到服务器中，并且将该 token 返回给 APP 端。
以后 APP 再次请求时，凡是需要验证的地方都要带上该 token，然后服务器端验证 token，成功返回所需要的结果，失败返回错误信息，让用户重新登录。其中，服务器上会给 token 设置一个有效期，每次 APP 请求的时候都验证 token 和有效期。
token 的存储
token 可以存到数据库中，但是有可能查询 token 的时间会过长导致 token 丢失（其实 token 丢失了再重新认证一个就好，但是别丢太频繁，别让用户没事儿就去认证）。
为了避免查询时间过长，可以将 token 放到内存中。这样查询速度绝对就不是问题了，也不用太担心占据内存，就算 token 是一个 32 位的字符串，应用的用户量在百万级或者千万级，也是占不了多少内存的。
token 的加密
token 是很容易泄露的，如果不进行加密处理，很容易被恶意拷贝并用来登录。加密的方式一般有：
在存储的时候把 token 进行对称加密存储，用到的时候再解密。文章最开始提到的签名 sign：将请求 URL、时间戳、token 三者合并，通过算法进行加密处理。
最好是两种方式结合使用。
还有一点，在网络层面上 token 使用明文传输的话是非常危险的，所以一定要使用 HTTPS 协议。
总结
以上就是对于 token 在用户身份认证过程中的简单总结。希望没有技术背景的产品经理们在和开发哥哥沟通的时候不要再被这些技术术语问住了。
作者：流年，互联网产品设计师，4 年互联网产品设计经验。
本文由 @流年 原创发布于人人都是产品经理。未经许可，禁止转载。
题图由作者提供
丸趣 TV 网 – 提供最优质的资源集合！
