首先我们要弄清楚普通的Http协议为什么要加入身份认证呢？ 因为Http协议是无状态性的，你的每一次请求都是相对独立的， 服务器需要知道你的用户身份再决定你可以访问什么样的资源。
基本认证 HTTP Basic Authentication
这种方式最简单，当请求某个资源时，服务器返回401。再次请求参数中需要携带用户名和密码，准确来说是用户名和密码组合后经过base64转码的一个字符串。优点是简单，缺点也很明显：base64很容易解码，就代表请求被截取后用户名密码就会泄露。对于服务端来说，每次都需要验证用户名和密码很不方便。
单独的APIKey认证
这种方式可以说是方法1的延伸。既然用户名和密码比较麻烦，那么请求时就在头信息中存储一个用户密钥用于验证身份，服务端有单独的区域存储密钥。缺点是当请求被截获后，密钥也会被盗用。而且长时间使用同一密钥更加的不安全。因为单一的密钥不安全，很多开发人员就在头信息（大部分是在Cookie中）添加多个字段，比如sessionid、uid、token。服务端通过验证多个参数，确定用户身份，如果session设置了一段时间后失效的机制，安全性就有了基本保障。
OAuth2.0
这种认证方式你可以理解为移动APP中的方式2。当用户首次访问是需要提供用户名、密码。服务端返回一个code。携带这个code请求认证服务器，认证服务器会返回给你一个会过期的密钥，存储在客户端本地。你全程都在和认证服务器沟通，从而保证了主服务端的安全性。
数字签名认证
前几种方式，当请求被截取后用户身份的相关字段都可以被获取到。 如果在请求正文中添加一个参数sign，这个参数是头信息中的密钥加上请求体参数在某种算法的作用上生成的一个MD5字符串。第一MD5是很难破解回原始值的，第二攻击者很难推算请求体参数和密钥的组合算法。
总的来说，服务器如果验证了密钥和MD5字符串全部正确，就说明身份正确且参数在传入过程中没有被篡改。
现在很多技术团队都选择Http/Restful接口类型，这种方式的好处是轻量且开发快捷，但安全性方面需要加入补充提升。 如果你在公司测试这类接口，就要注意接口的安全性尤其是用户身份认证的机制。