在不违反RESTful原则的情况下在Angular中进行身份验证和授权的最佳实践？

Question

我已经阅读了很多关于REST和Angular身份验证和授权的SO线程，但是我仍然不觉得自己对自己想做的事情有很好的解决方案。对于某些背景，我打算在AngularJS中构建一个我想支持的应用程序：

1. 访客访问受限
2. 身份验证后，基于角色的应用程序访问
3. 通过API进行身份验证

要求对REST
API的所有调用都必须通过SSL进行。我想在不破坏RESTful原则的情况下构建应用程序，即不将会话状态存储在服务器上。当然，必须在服务器端加强对客户端授权的任何处理。因为我们需要随每个请求传递整个状态，所以我知道我需要传递某种令牌，以便接收REST请求的后端服务器可以对调用进行身份验证和授权。

话虽如此，我的主要问题是身份验证-这里的最佳做法是什么？似乎讨论了许多不同的方法，以下是我发现的一些方法：

• http://broadcast.oreilly.com/2009/12/principles-for-standardized-rest-authentication.html
• http://frederiknakstad.com/2013/01/21/authentication-in-single-page-applications-with-angular-js/
• http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html

有人问过类似的问题（AngularJS最佳实践应用程序身份验证），但除非我对答案有误解，否则似乎暗示应该使用服务器会话，这违反了RESTful原则。

我对Amazon AWS和George
Reese文章的主要担心是，它似乎假定使用者是程序，而不是最终用户。共享机密可以提前发布给程序员，然后程序员可以在此处使用它对调用进行编码。这里不是这种情况-
我需要代表用户从应用程序调用REST API。

这种方法足够了吗？假设我有一个会话资源：

POST / api /会话

为用户创建一个新会话

要创建会话，您需要发布一个包含“用户名”和“密码”的JSON对象。

{
    "email" : "[e-mail]",
    "password" : "password"
}

卷曲示例

curl -v -X POST --data '{"username":"[e-mail]","password":"password"}' "https://app.example.com/api/session" --header "Content-Type:application/json"

响应

HTTP/1.1 201 Created {
    "session": {
        "id":"520138ccfa4634be08000000",
        "expires":"2014-03-20T17:56:28+0000"
    }
}

状态码

• 201-创建了新的会话
• 400-错误的请求，JSON对象无效或缺少必需的信息
• 401-未经授权，请检查电子邮件/密码组合
• 403-访问被拒绝，禁用的帐户或许可证无效

为了清楚起见，我省略了HATEOAS详细信息。在后端，将创建一个新的，持续时间有限的会话密钥，并将其与用户关联。在后续请求中，我可以将其作为HTTP标头的一部分传递：

Authorization: MyScheme 520138ccfa4634be08000000

然后，后端服务器将负责将其从请求中提取出来，找到关联的用户并执行该请求的授权规则。它可能还应该更新会话的到期时间。

如果所有这些都是通过SSL进行的，那么我是否应为应该防御的任何类型的攻击敞开大门？您可以尝试猜测会话密钥并将其放置在标题中，因此我想我可以另外将用户GUID附加到会话密钥上，以进一步防止暴力攻击。

自从我积极编写程序已有几年了，而我又回到了这里。抱歉，如果我感到困惑或不必要地重新发明轮子，只是希望根据到目前为止的阅读，在这里由社区来发表我的想法，看看它们是否通过了石蕊测试。

Answer 1

当有人询问REST身份验证时，我遵从Amazon Web
Services并基本上建议“这样做”。为什么？因为从“众人的智慧”的角度来看，AWS解决了该问题，该问题得到了很多人的广泛使用，大量分析和审查，这些人比大多数人更了解和关心什么提出了安全请求。安全是“不要重蹈覆辙”的好地方。在“肩上站着”方面，您可以做得比AWS差。

现在，AWS不使用令牌技术，而是使用基于共享机密和有效负载的安全哈希。可以说，它是一个更复杂的实现（带有其所有标准化过程等）。

但这有效。

缺点是它要求您的应用程序保留人员共享的机密（即密码），并且还要求服务器有权访问该密码的纯文本版本。这通常意味着密码将以加密方式存储，然后根据需要进行解密。与安全哈希技术相比，这要求服务器端密钥管理和其他事物的复杂性更高。

当然，任何令牌传递技术的最大问题是中间人攻击和重播攻击。SSL可以自然地缓解这些问题。

当然，您还应该考虑OAuth系列，它们有其自身的问题，尤其是在互操作性方面，但是如果这不是主要目标，那么这些技术肯定是有效的。

对于您的应用程序来说，令牌租约不是什么大问题。您的应用程序仍将需要在租约期限内运行，或者可以续订。为了做到这一点，将需要保留用户凭证或重新提示他们。就像对待其他任何东西一样，只需将令牌视为一流资源即可。如果可行，请尝试将一些其他信息与请求关联，然后将其捆绑到令牌（浏览器签名，IP地址）中，以增强局部性。

您仍然对（潜在的）重播问题持开放态度，在该问题中，同一请求可以发送两次。对于典型的哈希实现，时间戳是签名的一部分，可以将请求的生存期括起来。在这种情况下，解决方法有所不同。例如，每个请求都可以使用序列ID或GUID发送，并且您可以记录该请求已被播放以防止再次发生。不同的技术。