RESTful接口签名认证实现机制

RESTful接口

互联网发展至今,催生出了很多丰富多彩的应用,极大地调动了人们对这些应用的使用热情。但同时也为互联网应用带来了严峻的考验。具体体现在以下几个方面:

1.     部署方式的改变:当用户量不多的情况下,可能只需部署一台服务器就可以解决问题,但是当很多用户的情况下,为抗住高并发访问,需要组成应用集群对外提供服务;

2.     应用构建的改变:很多应用采用了多种技术解决方案,不同编程语言(如C,Java,Python),所以很难采用传统应用构建模式将不同模块整合进来;

3.     数据开放的改变:开放是互联网发展的必然,因为这种方式将应用本身的价值最大化了,同时用户可以基于已有功能生成特有需求应用,提高用户粘度,开放共赢。

而近观传统的Web应用,均为采用集中部署结构,基于某种特定技术开发完成,基于session或cookie等会话追踪机制。加上需要系统间交互信息,使得实现十分复杂,且可伸缩性、易用性、维护性极差。

基于以上矛盾,出现了一种新的互联网应用架构风格—REST(Representational StateTransfer)。最初这种思路出现在Roy Fielding博士的论文中,他也是HTTP规范的主要作者之一。REST充分利用HTTP的优势,以资源位核心,将资源的CRUD映射为HTTP的 GET PUT POST DELTE方法,服务端无需保存任何客户端信息。客户端的每次资源请求包含了服务端响应需要的所有语义信息。

我们可以看出,基于REST风格架构的应用特点是:互联网可以看成一个巨大的状态机,资源相当于状态,而URI相当于状态的表述。客户端通过访问不同资源,进行状态切换。服务端却无须记住这些状态,可通过横向扩展方式消除性能瓶颈。

但是,REST构建的应用如何进行安全控制呢?我们可不希望把自己暴露出去任人“宰割”。目前,常用的方式是OAUTH形式认证方式,这种方式适合对** 应用系统有很强依赖的时候考虑,比如新浪微博开放接口就采用这种。本文主要讲解基于token机制的签名认证模式。

具体签名规则

在用户可以使用REST接口之前,首先需要通过向REST接口开放方申请,当获准后会收到两个key:accessKey和secretKey。其中 accessKey相当于用户标识,应用会通过它区分不同用户,而secreKey相当于提供给用户的密码,在接口使用过程中都不会在网络中传输,只有用 户和应用系统知道。

用户对接口的每一次请求都会默认通过某种机制生成一个签名,然后发送给REST服务端。服务端收到后,会根据该机制验证该请求的合法性,从而避免非法用户的随意使用。

一般,签名以如下形式保存在HTTP Header中发送给REST服务器(其中oss为固定字,Signature是摘要内容):

token = “oss” + “ ”+ accessKey + “:” + Signature

计算的伪代码如下:

StringToSing =HTTP-Verb +”\n”+      //http请求的动作
            Content-MD5+”\n”+     //http请求的MD5值
            Content-Type+”\n”+     //http请求的类型
            Date+”\n”+            //http请求时间
            CanonicalizdResource;  //http请求资源

其中HTTP-Verb是http请求动作,对应于GET,PUT,DELETE,POST等(不能为空),Content-MD5表示请求内容数据的 MD5值(可以为空,以空字符代替,下同),Content-Type为请求的类型(可以为空),Date为本次操作的时间(不能为 空),CanonicalizdResource表示请求的资源(不能为空),当然我们还可以根据系统本身情况指定某些可选或必选参数。

Signature =BASE64(HMAC-SHA1(UTF-8-Encoding-Of(secretKey, StringToSign)))

采用utf-8提前对参数进行编码,可以减少客户端编码差异带来的影响,因为服务端到时是统一采用utf-8来做的,HMAC-SHA1生成签名摘 要指纹信息是不可逆的,安全性得到提高,最后还进行了BASE64编码的原因是将摘要内容全部转换为可显字符,应对某些不可显字符在网络传输中的丢失。

  服务端验证方式则是根据传输过来的token解析出accessKey和Singature,根据accessKey得到本地保存的对应 secretKey(注意其并未在网络中传输),然后再重新根据客户端Signature生成方式重新生成与解析的进行比较,相同则认证成功结束,否则, 直接返回错误信息给客户端。

  整个流程通过以下一张图,进一步阐述:

值得注意的是,JDK提供了java.securty包,里面有各种加密算法,用来进行代码的标识和身份认证。

术语解释

接下来简要的对常用的摘要算法及加密算法进行解释,方便具体使用过程中采取不同方式加强系统的安全性。

常用的哈希算法(生成指纹或签名)有MD5和SHA。MD5在文件完整性、网站登录和数字签名等领域有着广泛使用,理论上说MD5数字签名可以伪造,但说其已被破解,那只是杞人忧天罢了。SHA也是著名的哈希算法,不可逆算法,多用于数字签名的情况。

常用的对称加密算法有DES和AES。DES是老牌的加密算法,这是应用最广泛的密钥系统,也是可逆的对称加密算法。而AES是一种高级的加密标准,2002年成为标准,可用于替代DES,可逆对称加密算法。

常用的非对称公钥加密算法是RSA,多数网银采用的就是RSA算法来认证的。RSA的安全性依赖于大数的因子分解,它是第一个技能用于数据加密也能用于数字签名的算法,也是可逆算法。但是注意这种算法运算代价很高,速度比较慢,比DES之类算法要慢得多。

对于RSA啰嗦下,公钥和私钥成对出现。用公钥加密数据,用私钥解密数据(别人传数据给我);用私钥加密数据作为数字签名,用公钥来验证数字签名(我传数据给别人)。

时间: 2025-01-06 08:35:33

RESTful接口签名认证实现机制的相关文章

RESTful Api 身份认证安全性设计

REST是一种软件架构风格.RESTful Api 是基于 HTTP 协议的 Api,是无状态传输.它的核心是将所有的 Api 都理解为一个网络资源.将所有的客户端和服务器的状态转移(动作)封装到 HTTP 请求的 Method  之中. 详情可以阅读 http://mengkang.net/620.html . 而这篇文章则主要是讨论 RESTful Api 身份认证安全性设计. 没有绝对的安全,这个话题很深, 下文都是自己的一些理解,水平有限,如有勘误,希望大家予以指正. 由于 RESTfu

ASP.NET Core WebApi基于Redis实现Token接口安全认证

一.课程介绍 明人不说暗话,跟着阿笨一起玩WebApi!开发提供数据的WebApi服务,最重要的是数据的安全性.那么对于我们来说,如何确保数据的安全将会是需要思考的问题.在ASP.NET WebService服务中可以通过SoapHead验证机制来实现,那么在ASP.NET Core WebApi中我们应该如何保证我们的接口安全呢?  近年来RESTful API开始风靡,使用HTTP header来传递认证令牌似乎变得理所应当,而单页应用(SPA).前后端分离架构似乎正在促成越来越多的WEB应

app与php后台接口登录认证、验证(seesion和token)

简要:随着电商的不断发展,APP也层次不穷,随着科技的发展主要登录形式(微信.QQ.账号/密码):为此向大家分享一下"app与php后台接口登录认证.验证"想法和做法:希望能够帮助困惑的伙伴们,如果有不对或者好的建议告知下:*~*!  一.登录机制 粗略分析:登录可分为三个阶段(登录验证.登录持续.退出登录):登录验证指客户端提供账号/密码(或第三方平台(微信.qq)获取openid/unionid)向服务器提出登录请求,服务器应答请求判断能否登录并返回相应数据:登录持续指客户端登录后

前端调用后端的方法(基于restful接口的mvc架构)

1.前端调用后台: 建议用你熟悉的一门服务端程序,例如ASP,PHP,JSP,C#这些都可以,然后把需要的数据从数据库中获得,回传给客户端浏览器(其实一般就是写到HTML中,或者生成XML文件)然后在用JS获得. 2.js只是前端的语言,它还没有访问数据库的能力.不过它可以向某个URL发送请求,并获得返回的数据.这个会用到Ajax技术. 用AJAX,页面不刷新,只提交字符串到后台导入数据库       通过纯AngularJS+REST API构建Web是否可行? 在构建Web系统的时候,可不可

REST签名认证

139 开放平台与应用之间以REST协议进行通讯,为了保证通信的安全性,开放平台加入签名认证机制.应用一旦创建,系统生成唯一并且不公开的secretkey,只有应用的拥有者和开放平台知道.因此,当应用请求开放平台时,把请求的参数以及开放平台分配的secretkey进行MD5 HASH生成sig,从而保证通信的安全. 签名生成规则 把所有的请求参数按照字典顺序进行排序:注意:请把参数的连接符'&'去掉:例如:c=3&a=1&b=2排序后为a=1b=2c=3: 把排序后的字符串后面追加

简淡 RESTful 接口

今天眼睛有点痛,早点下班回来,不想做饭,顿觉无聊,掐指一算,还是写点想法吧.写东西也是一个休息吧.就聊一下互联网的应用程序接口吧. 互联网最流行的应用程序接口,莫过于 RPC 与 RESTful.两者的一个重要区别是如何对待客户端,RPC 把客户端视为整个系统的一部分,服务器与客户端之间紧密耦合.而 RESTful 刚好相反,客户端与服务器之间,仅需要一个入口 URL. 国内绝大多数 Api,包括新浪微博之类的 HTTP/JSON Api,都是 RPC,RPC 的一个常见的问题就是接口的管理问题

安全优雅的RESTful API签名实现方案(手机端)

安全优雅的RESTful API签名实现方案 1.接口签名的必要性 在为第三方系统提供接口的时候,肯定要考虑接口数据的安全问题,比如数据是否被篡改,数据是否已经过时,数据是否可以重复提交等问题.其中我认为最终要的还是数据是否被篡改.在此分享一下我的关于接口签名的实践方案. 2.项目中签名方案痛点 每个接口有各自的签名方案,不统一,维护成本较高. 没有对消息实体进行签名,无法避免数据被篡改. 无法避免数据重复提交. 3.签名及验证流程 4.签名规则 线下分配appid和appsecret,针对不同

RESTful 接口调试分享利器 restc

这个工具来自于https://elemefe.github.io/restc/  这里对Abp进行了一次封装 1.在项目中添加nuget包 Abp.Web.Api.Restc 2.在项目Abp模块的DependsOn添加AbpWebApiRestcModule Run It,启动项目,访问/api开头的restful接口 ,原先正常返回的干巴巴JSON数据变成了一个可以操作分享的UI界面了 项目源码https://github.com/yuzukwok/Abp.Web.Api.Restc大家可以

底层restful接口修改分析

记录接口调用次数,接口调用时间需求. 需要修改公共的类,就是restful接口,可以认为是底层的代码,具体的实现有哪些?插入数据库肯定不能影响性能. 底层restful接口修改分析,布布扣,bubuko.com