open api 的安全设计

Token Auth的优点

Token机制相对于Cookie机制又有什么好处呢？

• 支持跨域访问: Cookie是不允许垮域访问的，这一点对Token机制是不存在的，前提是传输的用户认证信息通过HTTP头传输.
• 无状态(也称：服务端可扩展行):Token机制在服务端不需要存储session信息，因为Token 自身包含了所有登录用户的信息，只需要在客户端的cookie或本地介质存储状态信息.
• 更适用CDN: 可以通过内容分发网络请求你服务端的所有资料（如：javascript，HTML,图片等），而你的服务端只要提供API即可.
• 去耦: 不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成，只要在你的API被调用的时候，你可以进行Token生成调用即可.
• 更适用于移动应用: 当你的客户端是一个原生平台（iOS, Android，Windows 8等）时，Cookie是不被支持的（你需要通过Cookie容器进行处理），这时采用Token认证机制就会简单得多。
• CSRF:因为不再依赖于Cookie，所以你就不需要考虑对CSRF（跨站请求伪造）的防范。
• 性能: 一次网络往返时间（通过数据库查询session信息）总比做一次HMACSHA256计算 的Token验证和解析要费时得多.
• 不需要为登录页面做特殊处理: 如果你使用Protractor 做功能测试的时候，不再需要为登录页面做特殊处理.
• 基于标准化:你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如：Firebase,Google, Microsoft）

====================

对Token认证的五点认识

对Token认证机制有5点直接注意的地方：

• 一个Token就是一些信息的集合；
• 在Token中包含足够多的信息，以便在后续请求中减少查询数据库的几率；
• 服务端需要对cookie和HTTP Authrorization Header进行Token信息的检查；
• 基于上一点，你可以用一套token认证代码来面对浏览器类客户端和非浏览器类客户端；
• 因为token是被签名的，所以我们可以认为一个可以解码认证通过的token是由我们系统发放的，其中带的信息是合法有效的；

生成token的时候用的是username + password 认证的。web 是https

对于服务器的话，用的是：rsa 传输加密后的appkey to get token.

//下面这种做法可以防止重放攻击。

1） open Api 很多博客讲到 token + 签名。

这里总结下

token ：脱敏

签名 ： 防篡改

timestamp: 进行超时校验 一般 60s

nonce ： 唯一的请求ID  有效时间60秒，就是结合timestamp 防止 nonce过多而设计

appsecurity_key 是私有的不可以泄露，用来加解密数据的，非对称加密算法key。

sign = md5 (order by paramKey and contact withe ‘=’ {appsecurity_key ,token,timestamp,nonce,params})

head params :token + sign + timestamp + nonce

params : 数据参数

接收请求验证参数：

0） 校验token是否有效 / 30分钟   在token中需要携带用户信息。

1） 判断超时60s 

2）判断是否请求过 nonce

3) 验证签名是否相等   / token 关联用户ID，然后可以查询 出该app的appkey

4）清理DB中nonce超时的

5）记录nonce in db

总结：token是在内网的使用的时候可以不用https，有可能传输导致数据泄露，但是此时任务仅仅是用来做应用授权。在公网上的时候用https。

基于JWT的Token认证的安全问题

确保验证过程的安全性

如何保证用户名/密码验证过程的安全性；因为在验证过程中，需要用户输入用户名和密码，在这一过程中，用户名、密码等敏感信息需要在网络中传输。因此，在这个过程中建议采用HTTPS，通过SSL加密传输，以确保通道的安全性。

基于token的多平台身份认证架构设计

1   概述

在存在账号体系的信息系统中，对身份的鉴定是非常重要的事情。

随着移动互联网时代到来，客户端的类型越来越多， 逐渐出现了 一个服务器，N个客户端的格局 。

不同的客户端产生了不同的用户使用场景，这些场景：

1. 有不同的环境安全威胁
2. 不同的会话生存周期
3. 不同的用户权限控制体系
4. 不同级别的接口调用方式

综上所述，它们的身份认证方式也存在一定的区别。

本文将使用一定的篇幅对这些场景进行一些分析和梳理工作。

2   使用场景

下面是一些在IT服务常见的一些使用场景:

1. 用户在web浏览器端登录系统,使用系统服务
2. 用户在手机端（Android/iOS）登录系统,使用系统服务
3. 用户使用开放接口登录系统,调用系统服务
4. 用户在PC处理登录状态时通过手机扫码授权手机登录（使用得比较少）
5. 用户在手机处理登录状态进通过手机扫码授权PC进行登录（比较常见）

通过对场景的细分,得到如下不同的认证token类别:

1. 原始账号密码类别

   • 用户名和密码
   • API应用ID/KEY

2. 会话ID类别

   • 浏览器端token
   • 移动端token
   • API应用token

3. 接口调用类别

   • 接口访问token

4. 身份授权类别

   • PC和移动端相互授权的token

3   token的类别

不同场景的token进行如下几个维度的对比:

天然属性 对比:

1. 使用成本

   本认证方式在使用的时候,造成的不便性。比如:

   • 账号密码需要用户打开页面然后逐个键入
   • 二维码需要用户掏出手机进行扫码操作

2. 变化成本

   本认证方式,token发生变化时,用户需要做出的相应更改的成本:

   • 用户名和密码发生变化时,用户需要额外记忆和重新键入新密码
   • API应用ID/KEY发生变化时,第三方应用需要重新在代码中修改并部署
   • 授权二维码发生变化时,需要用户重新打开手机应用进行扫码

3. 环境风险

   • 被偷窥的风险
   • 被抓包的风险
   • 被伪造的风险

可调控属性 对比:

1. 使用频率

   • 在网路中传送的频率

2. 有效时间

   • 此token从创建到终结的生存时间

最终的目标:安全和影响。

安全和隐私性主要体现在:

• token 不容易被窃取和盗用（通过对传送频率控制）
• token 即使被窃取,产生的影响也是可控的（通过对有效时间控制）

关于隐私及隐私破坏后的后果,有如下的基本结论:

1. 曝光频率高的容易被截获
2. 生存周期长的在被截获后产生的影响更严重和深远

遵守如下原则:

1. 变化成本高的token不要轻易变化
2. 不轻易变化的token要减少曝光频率（网络传输次数）
3. 曝光频率高的token的生存周期要尽量短

将各类token的固有特点及可控属性进行调控后, 对每个指标进行量化评分（1~5分），我们可以得到如下的对比表：

备注:

• user_name/passwd 和 app_id/app_key 是等价的效果

4   token的层级关系

参考上一节的对比表，可以很容易对这些不同用途的token进行分层，主要可以分为4层：

1. 密码层

   最传统的用户和系统之间约定的数字身份认证方式

2. 会话层

   用户登录后的会话生命周期的会话认证

3. 调用层

   用户在会话期间对应用程序接口的调用认证

4. 应用层

   用户获取了接口访问调用权限后的一些场景或者身份认证应用

token的分层图如下：

在一个多客户端的信息系统里面,这些token的产生及应用的内在联系如下:

1. 用户输入用户名和用户口令进行一次性认证
2. 在 不同 的终端里面生成拥有 不同 生命周期的会话token
3. 客户端会话token从服务端交换生命周期短但曝光 频繁 的接口访问token
4. 会话token可以生成和刷新延长 access_token 的生存时间
5. access_token可以生成生存周期最短的用于授权的二维码的token

使用如上的架构有如下的好处：

1. 良好的统一性。可以解决不同平台上认证token的生存周期的 归一化 问题
2. 良好的解耦性。核心接口调用服务器的认证 access_token 可以完成独立的实现和部署
3. 良好的层次性。不同平台的可以有完全不同的用户权限控制系统，这个控制可以在 会话层 中各平台解决掉

4.1   账号密码

广义的 账号/密码 有如下的呈现方式:

1. 传统的注册用户名和密码
2. 应用程序的app_id/app_key

它们的特点如下：

1. 会有特别的意义

   比如：用户自己为了方便记忆，会设置有一定含义的账号和密码。

2. 不常修改

   账号密码对用户有特别含义，一般没有特殊情况不会愿意修改。 而app_id/app_key则会写在应用程序中，修改会意味着重新发布上线的成本

3. 一旦泄露影响深远

   正因为不常修改，只要泄露了基本相当于用户的网络身份被泄露，而且只要没被察觉这种身份盗用就会一直存在

所以在认证系统中应该尽量减少传输的机会，避免泄露。

4.2   客户端会话token

功能：充当着session的角色，不同的客户端有不同的生命周期。

使用步骤：

1. 用户使用账号密码，换取会话token

不同的平台的token有不同的特点。

Web平台生存周期短

主要原因：

1. 环境安全性

   由于web登录环境一般很可能是公共环境，被他人盗取的风险值较大

2. 输入便捷性

   在PC上使用键盘输入会比较便捷

移动端生存周期长

主要原因：

1. 环境安全性

   移动端平台是个人用户极其私密的平台，它人接触的机会不大

2. 输入便捷性

   在移动端上使用手指在小屏幕上触摸输入体验差，输入成本高

4.3   access_token

功能：服务端应用程序api接口访问和调用的凭证。

使用步骤：

1. 使用具有较长生命周期的会话token来换取此接口访问token。

其曝光频率直接和接口调用频率有关，属于高频使用的凭证。 为了照顾到隐私性，尽量减少其生命周期，即使被截取了，也不至于产生严重的后果。

注意：在客户端token之下还加上一个access_token， 主要是为了让具有不同生命周期的客户端token最后在调用api的时候， 能够具有统一的认证方式。

4.4   pam_token

功能：由已经登录和认证的PC端生成的二维码的原始串号（Pc Auth Mobile）。

主要步骤如下：

1. PC上用户已经完成认证，登录了系统
2. PC端生成一组和此用户相关联的pam_token
3. PC端将此pam_token的使用链接生成二维码
4. 移动端扫码后，请求服务器，并和用户信息关联
5. 移动端获取refresh_token(长时效的会话)
6. 根据 refresh_token 获取 access_token
7. 完成正常的接口调用工作

备注:

• 生存周期为2分钟,2分钟后过期删除
• 没有被使用时,每1分钟变一次
• 被使用后,立刻删除掉
• 此种认证模式一般不会被使用到

4.5   map_token

功能：由已经登录的移动app来扫码认证PC端系统，并完成PC端系统的登录（Mobile Auth Pc）。

主要步骤：

1. 移动端完成用户身份的认证登录app
2. 未登录的PC生成匿名的 map_token
3. 移动端扫码后在db中生成 map_token 和用户关联（完成签名）
4. db同时针对此用户生成 web_token
5. PC端一直以 map_token 为参数查找此命名用户的 web_token
6. PC端根据 web_token 去获取 access_token
7. 后续正常的调用接口调用工作

备注:

• 生存周期为2分钟,2分钟后过期删除
• 没有被使用时,每1分钟变一次
• 被使用后,立刻删除掉

5   小结与展望

本文所设计的基于token的身份认证系统，主要解决了如下的问题：

1. token的分类问题
2. token的隐私性参数设置问题
3. token的使用场景问题
4. 不同生命周期的token分层转化关系

本文中提到的设计方法，在 应用层 中可以适用于且不限于如下场景中：

1. 用户登录
2. 有时效的优惠券发放
3. 有时效的邀请码发放
4. 有时效的二维码授权
5. 具有时效 手机/邮件 验证码
6. 多个不同平台调用同一套API接口
7. 多个平台使用同一个身份认证中心

至于更多的使用场景，就需要大家去发掘了。

关于如何在技术上实现不同token的生存周期问题，将在后续文章中进行介绍，敬请期待。

 

补充内容：关于具备生命周期的token的技术实现方式

1	http://www.cnblogs.com/beer/p/6030882.html

"过期不候"--具备生命周期的数据的技术实现方案

1   引言

本文可以作为之前的一个 原理性文章 对应的 技术实现部分 。

此处给出其上文的直达电梯：

http://www.cnblogs.com/beer/p/6029861.html

基于token的多平台身份认证架构设计

2   数据生命周期

所谓的 “数据生命周期” 是指：为数据设定一定的生存期限,过了这个时间后， 此数据就被删除掉（失效）。

在进行web开发的时候,有很多需求场景是要求数据是具有一定的生命周期，比如:

• 具有一定时效的用户登录会话
• 邀请码系统的时效控制
• 具有时效的二维码/短信/邮件验证系统
• 接口调用认证的token有效期
• 第三方授权的期限控制
• 分享内容的时效控制
• 记录一段时间的日志

本文将以如下两种数据库特性为例子来对此功能的实现进行介绍:

• mongodb
• redis

3   mongodb

3.1   实现方法

在mongodb中有个 TTL（Time To Live 生存时间）索引 功能:

TTL索引是一种特殊索引，通过这种索引 MongoDB 会过一段时间后自动移除集合中的文档。 这对于某些类型的信息来说是一个很理想的特性，例如: 机器生成的事件数据，日志，会话信息等，这些数据都只需要在数据库中保存有限时间。

• 如果你可以设定这个生命周期是多久他只要过了这段时间之后，它就会自动删除掉
• 删除的周期就是一分钟左右（和mongodb服务的负载有关），mongodb后台会进行周期性地检查这些索引字段

在 mongodb 中的实现方式:

db.ttl_log_session.createIndex( { "lastModifiedDate": 1 }, { expireAfterSeconds: 3600 } )

主要解释如下:

• 对 ttl_log_session 合集建立索引
• 索引字段为 lastModifiedDate
• 索引顺序是 升序
• 有效生存周期为 3600 秒

达到的效果:以 lastModifiedDate 时刻开始,经过 3600 秒之后,此文档会失效被删除掉。

3.2   过期时间精度

删除操作的一些注意事项:

• TTL索引  不能 保证过期数据会被立刻删除

  在文档过期和MongoDB从数据库中删除文档之间，可能会有延迟。

• 删除过期数据的后台任务每隔60秒运行一次

  在文档过期之后和后台任务运行或者结束之前，文档会依然存在于集合中（删除操作还没有完成）。

• 删除操作的持续实际取决于您的 mongod 实例的负载

  在两次后台任务运行的间隔间，过期数据可能会继续留在数据库中超过60秒。

4   redis

redis是一个内存数据库,它具备快速IO的特点。在性能上会比Mongodb进行大幅度提升。

4.1   实现方式

通过如下方式:

EXPIRE key seconds

为给定的key设置生存时间,当key过期时（生存时间为0）,它会被自动删除。

如下是一些设置生存时间相关的基本操作:

redis> SET cache_page "www.google.com"
OK

redis> EXPIRE cache_page 30  # 设置过期时间为 30 秒
(integer) 1

redis> TTL cache_page    # 查看剩余生存时间
(integer) 23

redis> EXPIRE cache_page 30000   # 更新过期时间
(integer) 1

redis> TTL cache_page
(integer) 29996

注意事项:

• 生存时间可以通过使用 DEL 命令来删除整个 key 来移除，或者被 SET 和 GETSET 命令覆写(overwrite)
• 如果使用 RENAME 对一个 key 进行改名，那么改名后的 key 的生存时间和改名前一样
• 将一个带生存时间的 key 改名成另一个带生存时间的 another_key ，这时旧的 another_key (以及它的生存时间)会被删除，然后旧的 key 会改名为 another_key

4.2   过期时间精度

• 在 Redis 2.4 版本中，过期时间的延迟在  1s 之内

  就算key已经过期，但它还是可能在过期之后一秒钟之内被访问到

• 在新的 Redis 2.6 以后的版本中，延迟被降低到 1ms 之内

5   小结

在进行web开发过程中,很多场合都需要用到数据的生命周期的功能。 关于如何实现此功能时,可以参考如下结论后再进行相应的技术选型:

本文关于 "数据生命周期" 主题的主要结论如下:

• 可以通过在web应用层上面做一些定时任务,但是那样的效率远没有直接在数据库层做操作要效率高
• 内存数据库（Reids）在过期时间精度上面的控制要远比磁盘数据库（MongoDB）要强得多,可能达到6万倍

在进行技术选型时注意在如下几个特性上进行比较：

1. IO速度
2. 数据持久化
3. 数据的备份和复制集
4. 数据库对多核心的利用
5. 数据库集群的部署的成本和难度
6. 开发的成本和难度

最终能够得出合适自己的技术方案，实现自己系统的功能。

参考： https://www.cnblogs.com/xiekeli/p/5607107.html