token

token

浅谈Token多平台身份认证架构设计思路

科技创新柠檬^ 发表了文章 • 0 个评论 • 40 次浏览 • 2021-04-27 17:42 • 来自相关话题

1、概述在存在账号体系的信息系统中,对身份的鉴定是非常重要的事情。随着移动互联网时代到来,客户端的类型越来越多, 逐渐出现了 一个服务器,N个客户端的格局 。不同的客户端产生了不同的用户使用场景,这些场景:有不同的环境安全威胁不同的会话生存周期不同的用户权限控... ...查看全部
1、概述

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

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

不同的客户端产生了不同的用户使用场景,这些场景:

  • 有不同的环境安全威胁

  • 不同的会话生存周期

  • 不同的用户权限控制体系

  • 不同级别的接口调用方式

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

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

2、使用场景

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

  • 用户在web浏览器端登录系统,使用系统服务

  • 用户在手机端(Android/iOS)登录系统,使用系统服务

  • 用户使用开放接口登录系统,调用系统服务

  • 用户在PC处理登录状态时通过手机扫码授权手机登录(使用得比较少)

  • 用户在手机处理登录状态进通过手机扫码授权PC进行登录(比较常见)

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

1、原始账号密码类别
  • 用户名和密码

  • API应用ID/KEY

2、会话ID类别
  • 浏览器端token

  • 移动端token

  • API应用token

3、接口调用类别
  • 接口访问token

  • 身份授权类别

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

3、token的类别

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

天然属性对比:
1、使用成本

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

  • 账号密码需要用户打开页面然后逐个键入

  • 二维码需要用户掏出手机进行扫码操作

2、变化成本

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

  • 用户名和密码发生变化时,用户需要额外记忆和重新键入新密码

  • API应用ID/KEY发生变化时,第三方应用需要重新在代码中修改并部署

  • 授权二维码发生变化时,需要用户重新打开手机应用进行扫码

环境风险

  • 被偷窥的风险

  • 被抓包的风险

  • 被伪造的风险

可调控属性对比:

1、使用频率

在网路中传送的频率

2、有效时间

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

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

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

  • token 不容易被窃取和盗用(通过对传送频率控制)

  • token 即使被窃取,产生的影响也是可控的(通过对有效时间控制)

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

  • 曝光频率高的容易被截获

  • 生存周期长的在被截获后产生的影响更严重和深远

遵守如下原则:

  • 变化成本高的token不要轻易变化

  • 不轻易变化的token要减少曝光频率(网络传输次数)

  • 曝光频率高的token的生存周期要尽量短

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

备注:user_name/passwd 和 app_id/app_key 是等价的效果

4、token的层级关系

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

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

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

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

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

token的分层图如下:

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

  • 用户输入用户名和用户口令进行一次性认证

  • 在 不同 的终端里面生成拥有 不同 生命周期的会话token

  • 客户端会话token从服务端交换生命周期短但曝光 频繁 的接口访问token

  • 会话token可以生成和刷新延长 access_token 的生存时间

  • access_token可以生成生存周期最短的用于授权的二维码的token

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

  • 良好的统一性。可以解决不同平台上认证token的生存周期的 归一化 问题

  • 良好的解耦性。核心接口调用服务器的认证 access_token 可以完成独立的实现和部署

  • 良好的层次性。不同平台的可以有完全不同的用户权限控制系统,这个控制可以在 会话层 中各平台解决掉

4.1、账号密码

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

  • 传统的注册用户名和密码

  • 应用程序的app_id/app_key

它们的特点如下:

1、会有特别的意义

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

2、不常修改

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

3、一旦泄露影响深远

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

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

4.2、客户端会话token

功能:

充当着session的角色,不同的客户端有不同的生命周期。

使用步骤:

用户使用账号密码,换取会话token

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

Web平台生存周期短

主要原因:

  • 环境安全性:由于web登录环境一般很可能是公共环境,被他人盗取的风险值较大

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

移动端生存周期长

主要原因:

  • 环境安全性:移动端平台是个人用户极其私密的平台,它人接触的机会不大

  • 输入便捷性:在移动端上使用手指在小屏幕上触摸输入体验差,输入成本高

4.3、access_token

功能:

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

使用步骤:

使用具有较长生命周期的会话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的身份认证系统,主要解决了如下的问题:

  • token的分类问题

  • token的隐私性参数设置问题

  • token的使用场景问题

  • 不同生命周期的token分层转化关系

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

  • 用户登录

  • 有时效的优惠券发放

  • 有时效的邀请码发放

  • 有时效的二维码授权

  • 具有时效 手机/邮件 验证码

  • 多个不同平台调用同一套API接口

  • 多个平台使用同一个身份认证中心

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

*来源于公众号-程序猿DD

如何设计一个安全可靠的 API 接口?

IM即时通讯王叫兽 发表了文章 • 0 个评论 • 144 次浏览 • 2020-07-06 11:39 • 来自相关话题

最近几年,随着RESTful API开始风靡,使用HTTP header来传递认证令牌似乎变得理所应当,通过 RESTful 的API 接口设计简化了系统架构, 减少了耦合性, 可以让所有模块各自独立的进行改进。不过,在实际的REST API 接口设计过程中,... ...查看全部

最近几年,随着RESTful API开始风靡,使用HTTP header来传递认证令牌似乎变得理所应当,通过 RESTful 的API 接口设计简化了系统架构, 减少了耦合性, 可以让所有模块各自独立的进行改进。

不过,在实际的REST API 接口设计过程中,我们需要考虑如何让鉴权变得更安全可靠,例如不会被第三方恶意请求或者保证传输过程中的数据安全以及防止重复提交,本文就一起聊一聊。


传统的Session 认证方式


首先,我们说一些传统的认证方式,众所周知,HTTP 协议是一种无状态的协议,而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证,那么下一次请求时,用户还要再一次进行用户认证才行,因为我们并不能知道是哪个用户发出的请求,所以为了让我们的应用能识别是哪个用户发出的请求,我们只能在服务器存储一份用户登录的信息,这份登录信息会在响应时传递给浏览器,告诉其保存为cookie,以便下次请求时发送给我们的应用,这样我们的应用就能识别请求来自哪个用户了,这就是传统的基于session认证。

而这种方式有很多问题:

首先,占用资源,这种方式需要每个用户经过认证之后,都要在服务端做一次记录,以方便用户下次请求的鉴别,通常而言session都是保存在内存中,而随着认证用户的增多,服务端的开销会明显增大。

其次,扩展性差: 客户端认证之后,服务端做认证记录,如果认证的记录被保存在内存中的话,这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源,在一些分布式的场景下会限制了负载均衡器的能力,会限制了应用的扩展能力。

第三,容易遭受攻击: 这种基于cookie来进行用户识别的认证方式, 很容易被截获,用户就会很容易受到跨站请求伪造的攻击。


基于Token 的鉴权方式


由于session 认证的诸多问题,因此出现了基于token 的鉴权方式,这种方式不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了,这就为应用的扩展提供了便利。

基于token 鉴权的工作流程如下:

  • 首先,客户端通过用户名密码来请求对应的API接口

  • 第二,服务器会验证用户的信息

  • 第三,服务器通过验证后会发送token给客户端

  • 第四,客户端存储token,并在每次请求时附送上这个token值

  • 第五,服务端验证token值,并返回数据

这种方式的典型代表就是JWT(Json web token , 它是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准((RFC 7519),该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息,该token也可直接被用于认证,也可被加密。

它的特点如下:

  • 体积小(一串字符串)。因而传输速度快

  • 传输方式多样。可以通过 HTTP 头部(推荐)/URL/POST 参数等方式传输

  • 严谨的结构化。它自身(在 payload 中)就包含了所有与用户相关的验证消息,如用户可访问路由、访问有效期等信息,服务器无需再去连接数据库验证信息的有效性,并且 payload 支持应用定制

  • 支持跨域验证,多应用于单点登录

JWT通常由三部分组成:

  • 头信息(header)

  • 消息体(payload)

  • 签名(signature)

如下所示:


// Header { "alg": "HS256", "typ": "JWT" }

// Payload { // reserved claims "iss": "a.com", "exp": "1d", // public claims "http://a.com": true, // private claims "company": "A", "awesome": true }

// $Signature HS256(Base64(Header) + "." + Base64(Payload), secretKey)

// JWT JWT = Base64(Header) + "." + Base64(Payload) + "." + $Signature



其工作流程如下:

  • 首先,客户端通过发送HTTP 请求把账号密码发送给服务短,通常使用的是POST请求, 服务器会校验账号与密码是否合法,如果一致,则根据密钥生成一个 token 并返回,客户端收到这个 token 并保存在本地。在这之后,需要访问一个受保护的路由或资源时,只要附加上 token(通常使用 Header 的 Authorization 属性)发送到服务器,服务器就会检查这个 token 是否有效,并做出响应。

  • 服务端接收到 token 之后,会逆向构造过程,解码出 JWT 的三个部分,这一步可以得到 sign 的算法及 payload,结合服务端配置的 secretKey,可以再次进行 $Signature 的生成得到新的 $Signature,与原有的 $Signature 比对以验证 token 是否有效,完成用户身份的认证,验证通过才会使用 payload 的数据。


如何保证接口安全性


要想实现接口的安全性,我们可以做到以下几点:

首先,我们需要采用HTTPS 对传输过程中的数据进行加密,避免使用HTTP 这种明文传输的协议,防止数据直接暴露在公网中,在使用HTTPS的同时要保证时间安全可靠的加密方法和SSL 协议,目前主流的是TLS1.2 和最新的TLS1.3。同时要对证书进行校验,因为即使是HTTPS协议,证书也是能够被伪造的。

其次,对接口设计一般会加入 token、timestamp和sign 这些参数,不同的参数有自己不同的用途:

  • timestamp,即时间戳,它是客户端调用接口时传入的当前时间戳,时间戳的目的是用于防止DoS攻击。每次调用接口时接口都会判断服务器当前系统时间和接口中传的的timestamp的差值,如果这个差值超过某个设置的时间,例如设置的时间是3分钟,那么这个请求将被拦截掉,如果在设置的超时时间范围内,是不能阻止DoS攻击的。timestamp机制只能减轻DoS攻击的时间,缩短攻击时间。如果黑客修改了时间戳的值可通过sign签名机制来处理。

  • sign,即签名,通常用于参数签名,防止参数被非法篡改,最常见的是修改金额等重要敏感参数, sign的值一般是将所有非空参数按照升续排序然后+token+key+timestamp+nonce(随机数)拼接在一起,然后使用某种加密算法进行加密,这种方式的好处就是,当被劫持后,修改其中的参数值,然后再继续调用接口,虽然参数的值被修改了,但是因为攻击者并不清楚sign是如何计算出来的,所以即可是篡改参数的值,但没法修改sign的值,当服务器调用接口前会按照sign的规则重新计算出sign的值然后和接口传递的sign参数的值做比较,如果相等表示参数值没有被篡改,如果不等,表示参数被非法篡改了,则不会返回真实的响应信息。

  • 此外,接口设计时候要实现幂等性操作,所谓的幂等性操作就是为了防止重复性运算,我们可以将生成的签名和key保存到redis 中,并且设置超时时间,过期自动删除,当有重复的值存在则不会处理,就可以防止重复提交,从而保证请求结果一致性。

其使用流程如下:

  1. 接口调用方(客户端)向接口提供方(服务器)申请接口调用账号,申请成功后,接口提供方会给接口调用方一个AppKey和一个APP Secret参数

  2. 调用方申请App Key 和 App Secret 在生成请求时,将参数拼接后进行加密,例如使用HMAC-SHA256 或MD5加密,然后将 App Key, 加密结果追加到请求上。sign=加密(appId + timestamp + key)

  3. 服务收到请求后,根据App Key识别出调用方,解密得到参数以及对时间进行对比,判断是否超时,然后从字典中查询到对应的App Secret,与请求参数拼接、加密,与请求中的签名进行对比,签名结果相同的为合法请求。

以上就是给API 接口设计的一些建议,仅供参考,在实际的应用中还可以追加一些公共的参数,例如Host、接口的版本等等参数去进行校验保证接口的安全性。



作者 | 阿文

转自 | CSDN公众号(ID:CSDNnews)


浅谈Token多平台身份认证架构设计思路

科技创新柠檬^ 发表了文章 • 0 个评论 • 40 次浏览 • 2021-04-27 17:42 • 来自相关话题

1、概述在存在账号体系的信息系统中,对身份的鉴定是非常重要的事情。随着移动互联网时代到来,客户端的类型越来越多, 逐渐出现了 一个服务器,N个客户端的格局 。不同的客户端产生了不同的用户使用场景,这些场景:有不同的环境安全威胁不同的会话生存周期不同的用户权限控... ...查看全部
1、概述

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

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

不同的客户端产生了不同的用户使用场景,这些场景:

  • 有不同的环境安全威胁

  • 不同的会话生存周期

  • 不同的用户权限控制体系

  • 不同级别的接口调用方式

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

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

2、使用场景

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

  • 用户在web浏览器端登录系统,使用系统服务

  • 用户在手机端(Android/iOS)登录系统,使用系统服务

  • 用户使用开放接口登录系统,调用系统服务

  • 用户在PC处理登录状态时通过手机扫码授权手机登录(使用得比较少)

  • 用户在手机处理登录状态进通过手机扫码授权PC进行登录(比较常见)

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

1、原始账号密码类别
  • 用户名和密码

  • API应用ID/KEY

2、会话ID类别
  • 浏览器端token

  • 移动端token

  • API应用token

3、接口调用类别
  • 接口访问token

  • 身份授权类别

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

3、token的类别

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

天然属性对比:
1、使用成本

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

  • 账号密码需要用户打开页面然后逐个键入

  • 二维码需要用户掏出手机进行扫码操作

2、变化成本

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

  • 用户名和密码发生变化时,用户需要额外记忆和重新键入新密码

  • API应用ID/KEY发生变化时,第三方应用需要重新在代码中修改并部署

  • 授权二维码发生变化时,需要用户重新打开手机应用进行扫码

环境风险

  • 被偷窥的风险

  • 被抓包的风险

  • 被伪造的风险

可调控属性对比:

1、使用频率

在网路中传送的频率

2、有效时间

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

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

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

  • token 不容易被窃取和盗用(通过对传送频率控制)

  • token 即使被窃取,产生的影响也是可控的(通过对有效时间控制)

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

  • 曝光频率高的容易被截获

  • 生存周期长的在被截获后产生的影响更严重和深远

遵守如下原则:

  • 变化成本高的token不要轻易变化

  • 不轻易变化的token要减少曝光频率(网络传输次数)

  • 曝光频率高的token的生存周期要尽量短

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

备注:user_name/passwd 和 app_id/app_key 是等价的效果

4、token的层级关系

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

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

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

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

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

token的分层图如下:

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

  • 用户输入用户名和用户口令进行一次性认证

  • 在 不同 的终端里面生成拥有 不同 生命周期的会话token

  • 客户端会话token从服务端交换生命周期短但曝光 频繁 的接口访问token

  • 会话token可以生成和刷新延长 access_token 的生存时间

  • access_token可以生成生存周期最短的用于授权的二维码的token

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

  • 良好的统一性。可以解决不同平台上认证token的生存周期的 归一化 问题

  • 良好的解耦性。核心接口调用服务器的认证 access_token 可以完成独立的实现和部署

  • 良好的层次性。不同平台的可以有完全不同的用户权限控制系统,这个控制可以在 会话层 中各平台解决掉

4.1、账号密码

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

  • 传统的注册用户名和密码

  • 应用程序的app_id/app_key

它们的特点如下:

1、会有特别的意义

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

2、不常修改

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

3、一旦泄露影响深远

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

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

4.2、客户端会话token

功能:

充当着session的角色,不同的客户端有不同的生命周期。

使用步骤:

用户使用账号密码,换取会话token

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

Web平台生存周期短

主要原因:

  • 环境安全性:由于web登录环境一般很可能是公共环境,被他人盗取的风险值较大

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

移动端生存周期长

主要原因:

  • 环境安全性:移动端平台是个人用户极其私密的平台,它人接触的机会不大

  • 输入便捷性:在移动端上使用手指在小屏幕上触摸输入体验差,输入成本高

4.3、access_token

功能:

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

使用步骤:

使用具有较长生命周期的会话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的身份认证系统,主要解决了如下的问题:

  • token的分类问题

  • token的隐私性参数设置问题

  • token的使用场景问题

  • 不同生命周期的token分层转化关系

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

  • 用户登录

  • 有时效的优惠券发放

  • 有时效的邀请码发放

  • 有时效的二维码授权

  • 具有时效 手机/邮件 验证码

  • 多个不同平台调用同一套API接口

  • 多个平台使用同一个身份认证中心

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

*来源于公众号-程序猿DD

如何设计一个安全可靠的 API 接口?

IM即时通讯王叫兽 发表了文章 • 0 个评论 • 144 次浏览 • 2020-07-06 11:39 • 来自相关话题

最近几年,随着RESTful API开始风靡,使用HTTP header来传递认证令牌似乎变得理所应当,通过 RESTful 的API 接口设计简化了系统架构, 减少了耦合性, 可以让所有模块各自独立的进行改进。不过,在实际的REST API 接口设计过程中,... ...查看全部

最近几年,随着RESTful API开始风靡,使用HTTP header来传递认证令牌似乎变得理所应当,通过 RESTful 的API 接口设计简化了系统架构, 减少了耦合性, 可以让所有模块各自独立的进行改进。

不过,在实际的REST API 接口设计过程中,我们需要考虑如何让鉴权变得更安全可靠,例如不会被第三方恶意请求或者保证传输过程中的数据安全以及防止重复提交,本文就一起聊一聊。


传统的Session 认证方式


首先,我们说一些传统的认证方式,众所周知,HTTP 协议是一种无状态的协议,而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证,那么下一次请求时,用户还要再一次进行用户认证才行,因为我们并不能知道是哪个用户发出的请求,所以为了让我们的应用能识别是哪个用户发出的请求,我们只能在服务器存储一份用户登录的信息,这份登录信息会在响应时传递给浏览器,告诉其保存为cookie,以便下次请求时发送给我们的应用,这样我们的应用就能识别请求来自哪个用户了,这就是传统的基于session认证。

而这种方式有很多问题:

首先,占用资源,这种方式需要每个用户经过认证之后,都要在服务端做一次记录,以方便用户下次请求的鉴别,通常而言session都是保存在内存中,而随着认证用户的增多,服务端的开销会明显增大。

其次,扩展性差: 客户端认证之后,服务端做认证记录,如果认证的记录被保存在内存中的话,这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源,在一些分布式的场景下会限制了负载均衡器的能力,会限制了应用的扩展能力。

第三,容易遭受攻击: 这种基于cookie来进行用户识别的认证方式, 很容易被截获,用户就会很容易受到跨站请求伪造的攻击。


基于Token 的鉴权方式


由于session 认证的诸多问题,因此出现了基于token 的鉴权方式,这种方式不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了,这就为应用的扩展提供了便利。

基于token 鉴权的工作流程如下:

  • 首先,客户端通过用户名密码来请求对应的API接口

  • 第二,服务器会验证用户的信息

  • 第三,服务器通过验证后会发送token给客户端

  • 第四,客户端存储token,并在每次请求时附送上这个token值

  • 第五,服务端验证token值,并返回数据

这种方式的典型代表就是JWT(Json web token , 它是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准((RFC 7519),该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息,该token也可直接被用于认证,也可被加密。

它的特点如下:

  • 体积小(一串字符串)。因而传输速度快

  • 传输方式多样。可以通过 HTTP 头部(推荐)/URL/POST 参数等方式传输

  • 严谨的结构化。它自身(在 payload 中)就包含了所有与用户相关的验证消息,如用户可访问路由、访问有效期等信息,服务器无需再去连接数据库验证信息的有效性,并且 payload 支持应用定制

  • 支持跨域验证,多应用于单点登录

JWT通常由三部分组成:

  • 头信息(header)

  • 消息体(payload)

  • 签名(signature)

如下所示:


// Header { "alg": "HS256", "typ": "JWT" }

// Payload { // reserved claims "iss": "a.com", "exp": "1d", // public claims "http://a.com": true, // private claims "company": "A", "awesome": true }

// $Signature HS256(Base64(Header) + "." + Base64(Payload), secretKey)

// JWT JWT = Base64(Header) + "." + Base64(Payload) + "." + $Signature



其工作流程如下:

  • 首先,客户端通过发送HTTP 请求把账号密码发送给服务短,通常使用的是POST请求, 服务器会校验账号与密码是否合法,如果一致,则根据密钥生成一个 token 并返回,客户端收到这个 token 并保存在本地。在这之后,需要访问一个受保护的路由或资源时,只要附加上 token(通常使用 Header 的 Authorization 属性)发送到服务器,服务器就会检查这个 token 是否有效,并做出响应。

  • 服务端接收到 token 之后,会逆向构造过程,解码出 JWT 的三个部分,这一步可以得到 sign 的算法及 payload,结合服务端配置的 secretKey,可以再次进行 $Signature 的生成得到新的 $Signature,与原有的 $Signature 比对以验证 token 是否有效,完成用户身份的认证,验证通过才会使用 payload 的数据。


如何保证接口安全性


要想实现接口的安全性,我们可以做到以下几点:

首先,我们需要采用HTTPS 对传输过程中的数据进行加密,避免使用HTTP 这种明文传输的协议,防止数据直接暴露在公网中,在使用HTTPS的同时要保证时间安全可靠的加密方法和SSL 协议,目前主流的是TLS1.2 和最新的TLS1.3。同时要对证书进行校验,因为即使是HTTPS协议,证书也是能够被伪造的。

其次,对接口设计一般会加入 token、timestamp和sign 这些参数,不同的参数有自己不同的用途:

  • timestamp,即时间戳,它是客户端调用接口时传入的当前时间戳,时间戳的目的是用于防止DoS攻击。每次调用接口时接口都会判断服务器当前系统时间和接口中传的的timestamp的差值,如果这个差值超过某个设置的时间,例如设置的时间是3分钟,那么这个请求将被拦截掉,如果在设置的超时时间范围内,是不能阻止DoS攻击的。timestamp机制只能减轻DoS攻击的时间,缩短攻击时间。如果黑客修改了时间戳的值可通过sign签名机制来处理。

  • sign,即签名,通常用于参数签名,防止参数被非法篡改,最常见的是修改金额等重要敏感参数, sign的值一般是将所有非空参数按照升续排序然后+token+key+timestamp+nonce(随机数)拼接在一起,然后使用某种加密算法进行加密,这种方式的好处就是,当被劫持后,修改其中的参数值,然后再继续调用接口,虽然参数的值被修改了,但是因为攻击者并不清楚sign是如何计算出来的,所以即可是篡改参数的值,但没法修改sign的值,当服务器调用接口前会按照sign的规则重新计算出sign的值然后和接口传递的sign参数的值做比较,如果相等表示参数值没有被篡改,如果不等,表示参数被非法篡改了,则不会返回真实的响应信息。

  • 此外,接口设计时候要实现幂等性操作,所谓的幂等性操作就是为了防止重复性运算,我们可以将生成的签名和key保存到redis 中,并且设置超时时间,过期自动删除,当有重复的值存在则不会处理,就可以防止重复提交,从而保证请求结果一致性。

其使用流程如下:

  1. 接口调用方(客户端)向接口提供方(服务器)申请接口调用账号,申请成功后,接口提供方会给接口调用方一个AppKey和一个APP Secret参数

  2. 调用方申请App Key 和 App Secret 在生成请求时,将参数拼接后进行加密,例如使用HMAC-SHA256 或MD5加密,然后将 App Key, 加密结果追加到请求上。sign=加密(appId + timestamp + key)

  3. 服务收到请求后,根据App Key识别出调用方,解密得到参数以及对时间进行对比,判断是否超时,然后从字典中查询到对应的App Secret,与请求参数拼接、加密,与请求中的签名进行对比,签名结果相同的为合法请求。

以上就是给API 接口设计的一些建议,仅供参考,在实际的应用中还可以追加一些公共的参数,例如Host、接口的版本等等参数去进行校验保证接口的安全性。



作者 | 阿文

转自 | CSDN公众号(ID:CSDNnews)