常用认证方式
在之前的文章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
1) 先由客户端向服务器发出一个验证请求。
2) 服务器接到此请求后生成一个随机数并通过网络传输给客户端（此为质疑）。
3) 客户端将收到的随机数提供给ePass，由ePass使用该随机数与存储在ePass中的密钥进行HMAC-MD5运算并得到一个结果作为认证证据传给服务器（此为响应）。
4) 与此同时，服务器也使用该随机数与存储在服务器数据库中的该客户密钥进行HMAC-MD5运算，如果服务器的运算结果与客户端传回的响应,结果相同，则认为客户端是一个合法用户
JWT
JWT 是JSON Web Token简写，用于发送通过签名和认证的东西，服务端可通过解析该值来验证是否有操作权限，是否过期等安全性检查等。
注：
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
https://www.cnblogs.com/Irving/p/4964489.html