几乎每个REST API都必须具有某种身份验证。最常见的标头之一称为授权。但是，我们在谈论认证，但是为什么要有Authorization标头？

身份验证和授权之间的区别对于理解RESTful API的工作方式以及为什么接受或拒绝连接尝试很重要：

身份验证是对连接尝试凭据的验证。此过程包括使用身份验证协议以纯文本或加密形式将凭据从远程访问客户端发送到远程访问服务器。
授权是对允许连接尝试的验证。成功进行身份验证后，将进行授权。
换句话说，身份验证表明您是您的身份，而授权则询问您是否有权访问特定资源。

我知道在REST API中我们使用Authorization标头进行身份验证（或同时进行两者）有点令人困惑，但是如果我们记得在调用API时我们正在请求访问某些资源，则意味着服务器应该知道是否它应该提供对资源的访问权限，因此在开发和设计RESTful API时，Authorization标头听起来不错。

基本认证
处理身份验证的最简单方法是使用HTTP基本身份验证。我们使用特殊的HTTP标头，在其中添加以base64编码的“ username：password”。

请注意，即使您的凭据已编码，也不会被加密！ 从基本身份验证中检索用户名和密码非常容易。 不要在纯HTTP上使用此身份验证方案，而只能通过SSL / TLS使用。

HMAC
基本身份验证的缺点之一是，我们需要在每次请求时都发送密码。 同样，它也无法防止篡改标题或主体。

另一种方法是使用HMAC（基于哈希的消息身份验证）。 实际上，我们无需发送密码，而是发送密码的哈希版本以及更多信息。 假设我们具有以下凭据：用户名用户名，密码密钥。

假设我们尝试访问受保护的资源：

首先，我们需要获取所需的所有信息并将其连接起来。

在这里，我们仅将HTTP动词和实际URL串联在一起。 我们也可以添加其他信息，例如当前时间戳，随机数或消息正文的md5，以防止篡改正文或防止重放攻击。 接下来，我们生成一个HMAC：

我们可以将以下摘要作为HTTP标头发送：

 

现在，服务器知道用户“用户名”正在尝试访问资源。 由于服务器具有所有信息，因此它也可以生成摘要。

请注意，服务器上未对“密码”进行加密，因为服务器需要知道实际值。 这就是为什么首选“秘密”而不是“密码”的原因。

即使黑客正在侦听对话，他们也无法使用身份验证信息将数据发布到用户的帐户详细信息中，也无法查看其他用户帐户或任何其他URL，因为这会改变摘要，并且黑客没有 服务器和客户端都拥有的秘密。

但是，由于黑客不会更改摘要，因此它可以随时访问用户的帐户。 这就是为什么要发送更多次信息（例如当前时间）和随机数的原因：

我们添加了两个额外的信息。 当前日期和一个我们仅使用一次的数字（一次）

 

由于客户端发送了随机数和日期，因此服务器可以重新构造摘要。 如果日期不在当前服务器时间的某个范围内（例如10分钟），则服务器可以忽略该消息，因为它可能是先前发送的消息的重播（请注意：该消息或者服务器或客户端 时间是错误的。这是处理限时验证时的常见问题！）。

随机数是一个仅使用一次的数字。 如果我们想再次访问同一资源，则必须更改此号码。 这意味着，即使我们在同一秒内访问资源，每次访问资源时，随机数都会不同，因此摘要也会不同。 这样，我们可以确定不会进行重放攻击。 每个请求仅有效一次，并且仅一次。

历史背景：
2007年12月，OAuth 1.0通过基于数字签名的框架解决了授权问题。它很安全而且很坚固。主要参与者开始采用它。 Google于2008年开始支持OAuth 1.0。到2010年，Twitter强制所有第三方应用使用其OAuth 1.0实施。

但是，OAuth 1.0需要加密实现和加密互操作性。虽然安全，但这对许多开发人员来说是一个挑战。

然后在2012年10月发布OAuth 2.0。

构建安全的OAuth解决方案并非易事。大型企业加入了OAuth标准组织，并以多种方式对其产生了影响。尽管OAuth 2.0的加密基础比OAuth 1.0易于实施，但新版本在安全级别上包含了许多折衷方案。

但是，对非浏览器实现的支持以及资源交付和授权的明确分离有助于使新标准对大型企业和更多企业更加可用。

在许多情况下，将OAuth 1.0用作客户端实现者不再可行。例如，2012年4月，Google不再使用OAuth 1.0，并且不再允许使用OAuth 1.0。但是，Twitter仍完全支持OAuth 1.0。欲了解更多信息，请点击此处。

很少看到OAuth 1.0的新授权服务器实现。但是，如果您的资源提供者仍然支持OAuth 1.0（并承诺继续支持它），并且您具有在密码学方面有丰富经验的开发人员，并且您具有良好的密钥管理功能，那么您仍然可以考虑使用OAuth 1.0。

这些都是很多“如果”，而OAuth 2.0几乎始终是当今的正确选择。如果您希望将OAuth与正确的密码结合使用，那么越来越多的趋势是将OAuth 2.0与密码扩展一起使用。如果您正在设计和开发新的API，则选择OAuth 2.0！

还在想该怎么办？比较两个版本的安全性属性，然后确定哪个适合您的实现。

 

OAuth 1.0
与运输无关。安全未委派给HTTPS / TLS。
创建于密码学，尤其是数字签名。数字签名用于证明消息的完整性和真实性。数字签名可以确保特定消息是从特定来源发送的，并且该消息和签名不会以任何方式被篡改。签名的消息与其来源相关。它不能被篡改或复制到另一个源，但是客户端实现可能特别复杂。
每个消息都经过单独的加密签名。如果通信中的单个消息构造或签名不正确，则整个交易将无效
基本签名工作流程。
工作流程示例
客户端应用程序向诸如Twitter之类的提供者进行注册。
Twitter为客户提供了该应用程序独有的消费者秘密。
客户端应用程序使用其唯一的消费者机密对Twitter的所有OAuth请求进行签名。
如果任何OAuth请求格式错误，数据丢失或签名不正确，则该请求将被拒绝。
注意：除令牌外，有些人还使用OAuth 1.0范围参数携带授权/权利。这可能是有用的架构考虑因素。

OAuth 2.0
取决于运输。 ：大多数安全防护都委派给HTTPS / TLS。错字，不正确的TLS配置，无法正确验证证书或底层库中的漏洞都可能导致中间人（MiTM）攻击，从而破坏所有OAuth通信。
以不记名令牌为中心。 ：这些易于集成，但对安全性却不是很好。承载令牌不提供内部安全机制。它们可以被复制或被盗，但是易于实现。
更轻松。 ：OAuth 2.0可用性更高，但要安全构建则困难得多。
灵活。 ：OAuth 1.0仅处理Web工作流程，但OAuth 2.0也考虑非Web客户端。
更好的职责分离。 ：处理资源请求和处理用户授权可以在OAuth 2.0中分离。
基本签名工作流程。

1. 工作流程示例：
   1.客户端应用程序向诸如Twitter之类的提供者进行注册。
   2.Twitter为客户端提供了该应用程序独有的客户端机密。
   3.客户端应用程序在每个请求中都包含客户端密码。
   4.如果任何OAuth请求格式错误，数据丢失或包含错误的机密，则该请求将被拒绝。

其他参考：
请记住，基本身份验证和OAuth版本必须通过SSL / TLS保护。 不应在纯HTTP上使用它们。

身份验证表明您是您的身份，而授权则询问您是否有权访问特定资源。 使用REST API时，必须记住从一开始就考虑安全性。

RESTful API通常使用GET（读取），POST（创建），PUT（替换/更新）和DELETE（删除记录）。 对于所有单个资源集合，用户或操作，并非所有这些都是有效的选择。 确保传入的HTTP方法对会话令牌/ API密钥以及关联的资源收集，操作和记录有效。

例如，如果您有一个用于图书馆的RESTful API，则不允许匿名用户删除图书目录条目，但是让他们获取图书目录条目是可以的。 另一方面，对于图书馆员来说，这两种都是有效的用法。

https://dzone.com/articles/restful-api-authentication-basics-1