zoukankan      html  css  js  c++  java
  • 关于 RESTFUL API 安全认证方式的一些总结

     

     

    常用认证方式

    在之前的文章REST API 安全设计指南使用 AngularJS & NodeJS 实现基于 token 的认证应用两篇文章中,[译]web权限验证方法说明中也详细介绍,一般基于REST API 安全设计常用方式有: 
    HTTP Basic

    Basic admin:admin 
    Basic YWRtaW46YWRtaW4= 
    Authorization: Basic YWRtaW46YWRtaW4=
     
    由于HTTP协议是无状态的,所有每次请求都得带上身份信息,基于Http basic验证就是简单的将用户名和密码base64编码放到header中,一般需要HTTPS,安全性较低,实现的方式可以基于代码实现也可以基于web容器配置apache,nginx等web服务器即可实现。

    HTTP Digest

    摘要认证 digest authentication,服务器端以nonce进行质询,客户端以用户名,密码,nonce,HTTP方法,请求的URI等信息为基础产生的response信息进行认证的方式。 
        ※ 不包含密码的明文传递 
        摘要认证步骤: 
         1. 客户端访问一个受http摘要认证保护的资源。 
         2. 服务器返回401状态以及nonce等信息,要求客户端进行认证。 
    HTTP/1.1 401 Unauthorized 
    WWW-Authenticate: Digest 
    realm="testrealm@host.com", 
    qop="auth,auth-int", 
    nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 
    opaque="5ccc069c403ebaf9f0171e9517f40e41" 
         3. 客户端将以用户名,密码,nonce值,HTTP方法, 和被请求的URI为校验值基础而加密(默认为MD5算法)的摘要信息返回给服务器。 
               认证必须的五个情报: 
    ・ realm : 响应中包含信息 
    ・ nonce : 响应中包含信息 
    ・ username : 用户名 
    ・ digest-uri : 请求的URI 
    ・ response : 以上面四个信息加上密码信息,使用MD5算法得出的字符串。

    Authorization: Digest 
    username="Mufasa", ← 客户端已知信息 
    realm="testrealm@host.com", ← 服务器端质询响应信息 
    nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", ← 服务器端质询响应信息 
    uri="/dir/index.html", ← 客户端已知信息 
    qop=auth, ← 服务器端质询响应信息 
    nc=00000001, ← 客户端计算出的信息 
    cnonce="0a4f113b", ← 客户端计算出的客户端nonce 
    response="6629fae49393a05397450978507c4ef1", ← 最终的摘要信息 ha3 
    opaque="5ccc069c403ebaf9f0171e9517f40e41" ← 服务器端质询响应信息 
         4. 如果认证成功,则返回相应的资源。如果认证失败,则仍返回401状态,要求重新进行认证。

         注意事项: 
         1. 避免将密码作为明文在网络上传递,相对提高了HTTP认证的安全性。 
         2. 当用户为某个realm首次设置密码时,服务器保存的是以用户名,realm,密码为基础计算出的哈希值(ha1),而非密码本身。 
         3. 如果qop=auth-int,在计算ha2时,除了包括HTTP方法,URI路径外,还包括请求实体主体,从而防止PUT和POST请求表示被人篡改。 
         4. 但是因为nonce本身可以被用来进行摘要认证,所以也无法确保认证后传递过来的数据的安全性。

       ※ nonce:随机字符串,每次返回401响应的时候都会返回一个不同的nonce。 
       ※ nounce:随机字符串,每个请求都得到一个不同的nounce。 
          ※ MD5(Message Digest algorithm 5,信息摘要算法) 
             1)用户名:realm:密码 ⇒ ha1 
             2)HTTP方法:URI ⇒ ha2 
             3)ha1:nonce:nc:cnonce:qop:ha2 ⇒ ha3

    WSSE(WS-Security)

        WSSE UsernameToken 
        服务器端以nonce进行质询,客户端以用户名,密码,nonce,HTTP方法,请求的URI等信息为基础产生的response信息进行认证的方式。 
        ※ 不包含密码的明文传递 
        WSSE认证步骤: 
         1. 客户端访问一个受WSSE认证保护的资源。 
         2. 服务器返回401状态,要求客户端进行认证。 
    HTTP/1.1 401 Unauthorized 
    WWW-Authenticate: WSSE 
    realm="testrealm@host.com", 
    profile="UsernameToken" ← 服务器期望你用UsernameToken规则生成回应 
    ※ UsernameToken规则:客户端生成一个nonce,然后根据该nonce,密码和当前日时来算出哈希值。 
         3. 客户端将生成一个nonce值,并以该nonce值,密码,当前日时为基础,算出哈希值返回给服务器。 
    Authorization: WSSE profile="UsernameToken" 
    X-WSSE:UsernameToken 
    username="Mufasa", 
    PasswordDigest="Z2Y......", 
    Nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 
    Created="2010-01-01T09:00:00Z" 
         4. 如果认证成功,则返回相应的资源。如果认证失败,则仍返回401状态,要求重新进行认证。

    API KEY

    一般会分配app_key,sign_key两个值,将通知过来的所有参数,除去sign本身,以及值是空的参数,按参数名字母升序排序,然后按参键值…参数n值n的方式进行连接, 
    得到一个字符串然后在连接后得到的字符串前面加上通知验证密钥(sign_key, 不同于app_key),然后计算sha1值,转成小写 
    比如请求的参数为: 
    ?sign=9987e6395c239a48ac7f0d185c525ee965e591a7&verifycode=123412341234&app_key=ca2bf41f1910a9c359370ebf87caeafd&poiid=12345&time 
    stamp=1384333143&poiname= 海底捞(朝阳店)&v=1 
    去掉sign参数,其余的按参数名升序排列:app_keyca2bf41f1910a9c359370ebf87caeafdpoiid12345poiname海底捞(朝阳店)timestamp1384333143v 
    1verifycode123412341234 
    假设sign_key为21be83530509abc81aa945a02bec37601cf3cc21,我们把sign_key放在上面的字符串的前面:21be83530509abc81aa945a02bec37601c 
    f3cc21app_keyca2bf41f1910a9c359370ebf87caeafdpoiid12345poiname海底捞(朝阳店)timestamp1384333143v1verifycode123412341234 
    计算sha1()结果为:9987e6395c239a48ac7f0d185c525ee965e591a7

    微信V3支付与美团券(以上是美团核销券文档摘录)采用此种方式,对外有一个统一的服务网关,一般如果设计到安全性重要的接口,再加上数字证书(如微信支付的退款接口),适用服务端对服务端的应用。

    OAUTH 2.0

    OATH2设计更侧重对资源的授权,OAUTH2规范定义了Authorization Code,Resource Owner Password Credentials,Client Credentials ,Implicit Grant几种实现方式,具体看:OAuth2.0基础概述,Authorization Code 模式侧重对第三方用户资源的授权(如QQ联合登录,微博开放平台等),Resource Owner Password Credentials 侧重对个人用户资源授权(如App),Client Credentials 侧重对客户端的资源授权,Implicit Grant 是一种最简化模式,如网页中JS中调用,适用场景比较局限。

    HMAC

    ASP.NET Web API Security Filters

    1) 先由客户端向服务器发出一个验证请求。 
    2) 服务器接到此请求后生成一个随机数并通过网络传输给客户端(此为质疑)。 
    3) 客户端将收到的随机数提供给ePass,由ePass使用该随机数与存储在ePass中的密钥进行HMAC-MD5运算并得到一个结果作为认证证据传给服务器(此为响应)。 
    4) 与此同时,服务器也使用该随机数与存储在服务器数据库中的该客户密钥进行HMAC-MD5运算,如果服务器的运算结果与客户端传回的响应,结果相同,则认为客户端是一个合法用户

    JWT

    JWT 是JSON Web Token简写,用于发送通过签名和认证的东西,服务端可通过解析该值来验证是否有操作权限,是否过期等安全性检查等。

    3

    注: 
    HTTP Digest与WSSE认证来源 http-wsse和http-digest两种认证方式的区别

    支付接口安全性[服务端对服务端]

    支付宝:统一接口网关,RSA双向签名验证

    微信:API KEY方式+数字证书

    银联:RSA+数字证书

    App适用的授权方式

    • 跟用户没有关系的资源 Client Credentials,HMAC或API KEY,如果Token被抓包或APIKEY被反编译,不保证安全性,但是可以杜绝大部分的垃圾请求。
    • 跟用户有关系的资源 Resource Owner Password Credentials
    • 基于JWT实现
    • 基于Resource Owner Password Credentials 自定义实现发放Token

    ASP.NET WBAPI资源安全设计

    Securing ASP.NET Web APIs

    http://sddconf.com/brands/sdd/library/Securing_ASPdotNET_web_APIs.pdf

    Pro ASP.NET Web API Security

    服务设计参考

    Github 
    https://developer.github.com/v3/ 
    API V3 上线,实现 OAuth 2 认证 
    https://ruby-china.org/topics/25630 
    有赞 API 文档【appkey与oauth2】 
    http://open.koudaitong.com/doc

    REFER: 
    [译]web权限验证方法说明 
    http://segmentfault.com/a/1190000004086946 
    开放接口的安全验证方案(AES+RSA) 
    http://wustrive2008.github.io/2015/08/21/%E5%BC%80%E6%94%BE%E6%8E%A5%E5%8F%A3%E7%9A%84%E5%AE%89%E5%85%A8%E9%AA%8C%E8%AF%81%E6%96%B9%E6%A1%88%28AES+RSA%29/ 
    RESTful Api 身份认证安全性设计 
    http://mengkang.net/625.html

    大话接口隐私与安全
    https://blog.thankbabe.com/2016/06/05/donot-touch-my-url/

    API 客户端认证那些事

    http://mousycoder.com/2016/02/22/api-authentication/ 
    REST API Authentication 
    http://stackoverflow.com/questions/7999295/rest-api-authentication 
    Best Practices for securing a REST API / web service 
    http://stackoverflow.com/questions/7551/best-practices-for-securing-a-rest-api-web-service 
    Best practices for API versioning 
    http://stackoverflow.com/questions/389169/best-practices-for-api-versioning

  • 相关阅读:
    进制
    流程控制
    运算符
    格式化输出
    数据结构-树的遍历
    A1004 Counting Leaves (30分)
    A1106 Lowest Price in Supply Chain (25分)
    A1094 The Largest Generation (25分)
    A1090 Highest Price in Supply Chain (25分)
    A1079 Total Sales of Supply Chain (25分)
  • 原文地址:https://www.cnblogs.com/yelanggu/p/9956312.html
Copyright © 2011-2022 走看看