sessionStorage或localStorage 保存后台自己生成的特殊密码。每次请求通过head带上，通过后台验证数据合法

如果后端是分布式的话（比如云服务器），建议使用 oauth2.0中的token验证方式，如果只是开发的话，可以用cookie。
oauth登录流程如下:

1. 新建token表，字段 token,user_id,login_at,expire_at

2. 用户使用账号密码登录

3. 登录成功则在数据表token插入一条记录，并把该用户之前所有token删除或者设置为过期，并把token返回给前端

4. 前端使用ajax的时候添加headerAuthorization=token

5. 后端读取请求头中的Authorization，并与数据库比对，如果存在且未过期，则视为合法用户，否则返回错误

1 用户登录一般就是cookie + session，服务器不是同一台也一样呀，其中一台多一个请求转发功能就好了，因为同源策略的限制，访问另一个域名是不能带上cookie的。

2 一般会在前端会有个摘要函数来生成数据的摘要，虽然随数据post上去，然后后端用同样的摘要函数生成post上来的数据的摘要，与post上来的摘要进行比对，如果一致就证明数据没被修改过。但是用户如果知道你用的摘要函数是什么它也可以自己生成数据的摘要post上去，所以其实理论上是没法判断的，但实际中普通用户并不知道这些。

1. JWT, json web token.

2. 后端怎么判断这个数据是否被更改? 什么意思? 后端db不是存了数据吗?

后端数据验证，这个是前后端分离数据安全必须要做的。
通常的做法就是做sign加密
需要用到的是key和secret
比如淘宝api的加密方式 淘宝sign

key为用户标识，表名你是谁，secret代表你的钥匙。钥匙为服务端生成，只能在客户端加密时使用，在数据传输过程中不能包含sercet信息。
客户端根据特定规则对所有请求数据进行加密后，后端获取到所提交的数据在用同样方式加密，然后对比sign参数是否一致，一致则说明数据在传输过程中未遭到篡改。
另外还需要时间的时效性检测比如timestamp参数，要求时间误差不得超过前后5分钟
还有一点，数据重复请求，后端接收到sign后做个cache把sign存起来，失效时间5分钟（和上面时间对应），同一个sign表示本次请求已经重复请求过，然后拒绝

基本上都是这个流程，保证数据安全，时效性，防重复等。