认证Authentication 是验证用户身份的过程，当用户要访问受保护的资源时，将其信息发送到服务器进行验证的过程。
授权Authorization 是验证一个已经通过认证的用户是否有权限访问。
认证有如下几种模式：Basic，Digest，Bearer
Basic，基本认证。将用户名，密码以冒号分隔，并对组合后的字符串进行base64编码。这种编码是基于字符串中有不兼容的字符不能正常传输。安全性差，强烈建议在https中使用。
Digest，摘要认证。发送摘要信息，通过nonce，以及对于的key，做md5处理后生成对应的签名和服务器端效验。
Bearer，主要用户OAuth2.0中，也常用于Token中。
Token类型，包含两种一种是引用类型，另一种是自编码。
引用类型：由服务器根据相应规则生成的一串字符串，并通过此字符串和数据库或者缓存中的数据进行关联。
自编码类型：对用户信息（不包含密码）进行相应的编码，加密后发送给客户端使用。token本身包含用户的一些信息，所以不用通过查询数据库获取。JWT就是基于此项。
安全问题
当APP向全媒体系统提交HTTP请求时， 必须 附带若干URL参数，作为验证依据。
全媒体系统在收到请求时，会进行验证，并拒未通过绝验证的请求。
参数
timestamp 时间戳 形如： 1407812629434 注释：Java中的获取方法 – Date().getTime()
signature 签名 签名由 APPID , APPSECRET , timestamp 计算得出
算法
APP应将 signature 参数填写为 SHA1 哈希值的16进制字符串表达式
[Math Processing Error]
以 Python 语言举例:
>>> from hashlib import sha1
>>> appid = b'1001'
>>> appsecret = b'123456abcdef'
>>> timestamp = b'1407812629434'
>>> signature = sha1(appid + appsecret + timestamp).hexdigest()
>>> print(signature)
b1d11d44bcb28caa6ce4dc1b7f1526ede00f49e0
此时，url形如:
http://api/v1.0/1001/staffService/message?timestamp=1407812629434&signature=b1d11d44bcb28caa6ce4dc1b7f1526ede00f49e0
APP的安全验证
全媒体系统向APP发送HTTP请求是，也会在URL的参数部分附带验证数据。APP可以根据这些参数进行验证。
参数
timestamp 时间戳 形如： 1407812629434
signature 签名 签名由 APPID , ACCESSTOKEN , timestamp 计算得出
算法
全媒体系统将 signature 参数填写为 SHA1 哈希值的16进制字符串表达式
[Math Processing Error]
以 Python 语言举例:
>>> from hashlib import sha1
>>> appid = b'1001'
>>> accesstoken = b'6c9hgd@%#^5evc75@53Z5'
>>> timestamp = b'1407812629434'
>>> signature = sha1(appid + accesstoken + timestamp).hexdigest()
>>> print(signature)
04326e341d0ba7064975a9c03a75361f856d3341
此时，url形如:
http://apphost/staffService/message?timestamp=1407812629434&signature=04326e341d0ba7064975a9c03a75361f856d3341
Both timestamp and nonce are ways to prevent a man in the middle attack on an authentication mechansim. They work slightly differently, but the intent is the same - to provide a peice of data that is cryptographically built into the authentication mechanism that would make it difficult or impossible for an attacker to attack the system by replaying the message. A typical mechanism is authentication via digital signature. In either case, here's the steps:
1 - make message, attach timestamp or nonce to message
2 - hash both the message and the timestamp or nonce
3 - encrypt the hash with the private key (ie, sign it)
4 - send signature and message and nonce/timestamp
(this is the point at which the attacker gets a hold of it.
5 - recipient gets message.
6 - recipient checks that the signature matches the sent data (repeat step 2, decrypt signature with public key, compare to hash)
7 - recipient checks timestamp or nonce:
a - check timestamp - the value of the timestamp must be within an acceptable range of the current time. Ideally, the whole system is served by a timestamp server that defines to a tight precision what the "current time" is. If not, the system risks false negatives where the recipient incorrectly decides that the message time stamp is too old (or hasn't yet occured) do to a current time mismatch.
b - check nonce - verify that the nonce that was received has never before been received from this sender. Since the hash is unique to the contents of the message, this message MUST have come from the authorized sender, because this message is not being replayed.
8 - recipient performs any further authorization and access control checks.
The important things are:
either the timestamp or the nonce MUST be part of the signature
the timestamp is good if you are concerned about replay within a given time, but it requires good synchronization between servers and it will always assume some spectrum of error as many messages may be sent in a current spectrum of time - for example, if the timestamp is down to the second, then multiple message (including replays) could be sent in that second.
the nonce requires some level of persistence, since it only works if uniqueness is guaranteed and checked. Also, if the man in the middle can interrupt the sender, get the nonce, and keep the sender from sending it, the man in the middle attack could still be successful.