发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 CQRS 扩展性 并发编程 事件溯源 分布式 SOA

身份验证中Cookies与 Tokens比较

         
2014-01-08 13:19
赞助商链接



后端服务器有两种基本的身份验证:

1.是基于Cookie的身份验证,使用服务器端的cookie来对每次请求的用户进行身份验证。

2. 较新的方法,基于令牌Token-Based的认证,依赖于被发送到服务器上每个请求的签署令牌。

下图两个工作原理:


为什么基于令牌token-based的方式更好呢?理由如下:
1。跨域 / CORS: cookies + CORS 并不能跨不同的域名.而基于令牌能够使用 AJAX 调用服务器,在任何域名下你都可以使用HTTP header头部来传输用户信息。

2. 无态(代表服务器端可伸缩): 没有必要将会话保存,令牌 token 自己是一个自我包容的实体,包含用户各种信息,其他状态信息可以保存在cookie或客户端本地存储器中

3.CDN: 能够适用来自CDN任何应用部件(e.g. javascript, HTML, images, etc.), 你的服务器只是一个 API.

4.解耦: 你不必和一个特定的验证格式Schema绑定,令牌token 能在任何地方产生,这样的你的API可以在任何地方以同一种验证方式调用验证。

5.对移动Mobile友善: 当你在一个原生平台(iOS, Android, Windows 8, etc.)时, cookies依赖于一个安全API,并不是好主意,因为你得和一个cookie容器打交道,而基于令牌则简单多。

6.CSRF: 因为你不依赖cookies, 你就不需要跨请求保护,(e.g. it 有可能来自 <iframe> 请求一个POST,需要重用一个存在的验证。).

6.性能:一个网络往返(如发现在数据库中的会话)可能会比计算的HMACSHA256验证令牌耗费更多时间。

7.登录页面不是一个特殊情况,如果你如果您正在使用量角器来写你的功能测试,你不需要来处理登录的任何特殊情况。

8.基于标准: 你的API能接受一个标准的 JSON Web Token (JWT). 这个标准后面有多个库包(.NET, Ruby, Java, Python, PHP),许多公司支持(e.g. Firebase, Google, Microsoft). ,比如Firebase允许他们的客户使用任何身份验证机制,只要你使用预先定义的属性生成一个 JWT,并使用共享密钥签署,就能调用它们的API.

2
权限      单点登录     

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系反馈 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com