如何设计一个好的 RESTful API 来确保安全性

保证 RESTful API 的安全性主要有三个方面：

a） 对客户端进行身份验证。

b） 加密敏感数据并防止篡改。

c） 身份验证后的授权。

有几种常用方法可以对客户端进行身份验证：

向请求添加签名参数。

1.为每个访问方分配一个密钥，并指定一个签名计算方法。 访问方必须添加正数个签名的请求。

这是最简单的，但需要确保访问密钥安全存储，还需要注意防止重放攻击。 优点是易于理解和实现，但缺点是需要承担安全保管密钥并定期更新的负担，且不够灵活，难以更新密钥和升级签名算法。

使用标准的 HTTP 身份验证机制。

HTTP 基本身份验证的安全性较低，必须与 HTTPS 一起使用。 HTTP 摘要式身份验证可以单独使用，安全性中等。

HTTP Digest 认证机制还支持插入用户自定义的加密算法，可以进一步提高 API 的安全性。 但是，在面向 Internet 的 API 中，插入自定义加密算法并不常见。

这种方法需要保证访问方的“安全域-用户名-密码”三元组信息的安全存储，同时也要注意防止重放攻击。

优点：基于标准，广泛支持（大量HTTP服务器端，客户端库）。 服务器端的 HTTP 身份验证责任可以由 Web 服务器（例如 Nginx）、应用服务器（例如 Tomcat）和安全框架（例如 Spring Security）承担，这对应用程序开发人员是透明的。

HTTP 身份识别和告白机制 （RFC 2617） 是“关注点分离”设计原则的一个很好的例子，同时保持了操作语义的可见性。

2.缺点：这种基于用户名+密码的简单机制不太可能比基于非对称密钥的机制（例如数字证书）更安全。

使用 OAuth 协议进行身份认证。

当外部应用程序被授权访问此站点的资源时，OAuth 协议适用。 加密机制比 HTTP 摘要式身份验证更安全。 需要注意的是，OAuth 认证和 HTTP 摘要认证是不可互换的，它们的应用场景不同。

OAuth 协议更适合授权最终用户 API，例如获取属于用户的微博信息。 如果 API 不是面向终端用户的，比如七牛云存储这样的存储服务，这不是 OAuth 协议的典型应用场景。