后端写成的API，前端通过AJAX来访问，使用用户登录后后端给的cookie用来给API鉴权可行吗？
发现大部分网站的API都是通过OAuth，还有token之类的，不知道怎么实现，为什么不通过用户登录的cookie来鉴权呢？有什么缺点么？
Cooke存储在客户端，因此有可能被篡改，所以不可靠。
当然也可以通过加密Cookie来改善，更改了Cookie就失效。
我们知道HTTP协议是一种无状态的协议，及客户端和服务器端不需要建立持久的链接。客户端和服务器的链接是基于一种请求应答模式。
但是cookie需要在http头中传输，而token只需要在url中传输。总得来说，token有以下优势是cookie不具备的。
跨域 / CORS: cookies + CORS 并不能跨不同的域名.而基于令牌能够使用 AJAX 调用服务器，在任何域名下你都可以使用HTTP header头部来传输用户信息。
无态(代表服务器端可伸缩): 没有必要将会话保存，令牌 token 自己是一个自我包容的实体，包含用户各种信息，其他状态信息可以保存在cookie或客户端本地存储器中
CDN: 能够适用来自CDN任何应用部件(e.g. javascript, HTML, images, etc.), 你的服务器只是一个 API.
解耦: 你不必和一个特定的验证格式Schema绑定，令牌token 能在任何地方产生，这样的你的API可以在任何地方以同一种验证方式调用验证。
对移动Mobile友善: 当你在一个原生平台(iOS, Android, Windows 8, etc.)时， cookies依赖于一个安全API，并不是好主意，因为你得和一个cookie容器打交道，而基于令牌则简单多。
CSRF: 因为你不依赖cookies, 你就不需要跨请求保护，(e.g. it 有可能来自 <iframe> 请求一个POST，需要重用一个存在的验证。).
性能:一个网络往返（如发现在数据库中的会话）可能会比计算的HMACSHA256验证令牌耗费更多时间。
登录页面不是一个特殊情况，如果你如果您正在使用量角器来写你的功能测试，你不需要来处理登录的任何特殊情况。
基于标准: 你的API能接受一个标准的 JSON Web Token (JWT). 这个标准后面有多个库包(.NET, Ruby, Java, Python, PHP)，许多公司支持(e.g. Firebase, Google, Microsoft). ，比如Firebase允许他们的客户使用任何身份验证机制，只要你使用预先定义的属性生成一个 JWT，并使用共享密钥签署，就能调用它们的API.