前端把account和password，提交到服务端的登录api，服务端验证正确后，生成一个token，并把token和userId，存在缓存里（推荐redis数据库），然后把token返回给前端。前端每次的请求头中带token，这样就能够轻松的实现

楼上说的基本上现在都是这么做的吧，至少我没有见过其他更多的更好的方法
restapi这边基本都是用token来做的
如果要更安全的话
就是前后端的数据加密了
1.HTTPS是一方面，保证数据在传输的过程中不被篡改
2.另外可以做的可以考虑对参数加密，比如我前端传参的时候ABC三个参数，是按照你既定的规则来加密的，最后传输到后台的实际上是一个加密的字符串，后台再根据规则来解密得到参数，响应的json也一样处理。
这样一定程度可以防止

居然用token的被采纳了, 难道每一个url都加上token吗? 呵呵
说说我的:
其实还是用cookie的啊, 跟原来没啥区别:

1. client发送username和password到server

2. server验证成功后, 写cookie到client,然后返回ok的json, 其中cookie的key要存储在redis中,value就是用户信息, 并且要设置key的超时时间,如:60分钟

3. client收到ok后, 进行相应的业务操作, 以后每次请求server都会自动带上cookie, 不用你写代码

4. server端的filter(你肯定用filter来实现)中会每次验证传过来的cookie的key在redis中是否存在, 有就代表登录成功过可以操作, 没有就返回错误标识
   注意: 在登录成功后, 每次调用服务器接口时候, 都要为redis的key进行续期,如60分钟

5. 当redis的key超过60分钟, 自己会删除这个key, 那么再次请求server时, 就会收到需要登录的返回值

6. 当用户主动退出系统的时候, 也要在server中删除redis的key

再来说说token:
token一般用来做显示的身份验证, 比如手机验证码之类的, 这些都需要手动传递token到后台

1. 在client点击验证码

2. server发送验证码,返回给client一个token

3. 在client对验证码进行验证,传递token + 验证码到server

4. server对token+验证码进行验证

问题聚焦错了，前后端分离登录和跨域是两个问题，redis支持共享session token认证方式是另一种，总之看业务，我觉得权限管理自己开发比较好。协议自己设计