如何以宁静的方式实现身份验证？

Question

我正在使用python在web应用程序谷歌应用引擎上构建图片日记。用户可以在日记中注册并发布图片。

另外，我正在努力尽可能地遵循REST架构的做法。

对于Web应用程序，身份验证方案是这样的：
1.从前端发布用户名/密码
2.如果验证成功，后端会设置cookie 3.使用此cookie对其余的AJAX调用进行身份验证。

有没有办法在不使用cookie的情况下符合REST？

现在，我还在构建一个Android应用程序，用户可以登录并发布/查看他们的图片日记。我需要从Web应用程序的数据存储区公开数据，因此我将构建一个Web服务来从数据存储区中获取数据。

android客户端的身份验证方案：
  选项a 1.通过https将用户名/密码发布到Web服务
2. Web服务返回唯一的授权令牌（将令牌存储在数据存储区的username / pwd表中）
3.通过将此令牌添加到请求的请求标头来请求后续服务 4.服务器将令牌映射到用户名/ pwd表，如果找到令牌，则返回数据 5.授权令牌在一段时间后到期

选项b
1.在客户端和服务器端设置密钥
2.在每个请求的授权标题中使用“用户名：密码和密钥的哈希值” 3.服务器通过使用相同的哈希算法从哈希值中提取密码来生成密码;如果成功返回数据
顺便说一句，由于其安全漏洞，我不想使用基本授权。

哪个更好？

还有其他明显更好的方法来完成我想要做的事情吗？对我来说，安全性是一个令人担忧的问题 如果有人对此问题有任何了解，我将不胜感激。谢谢。

---

我自己一直在研究什么是最好的解决方案。我认为，正如莱昂姆所建议的那样，双腿的oauth可能会起作用 在这种情况下，服务器必须为客户端提供一个消费者密钥/秘密，在我的情况下，在应用程序中硬编码。

现在的步骤是：
1.使用oauth_parameters（consumer_key，signature_method，timestamp），请求URL，请求参数和SECRET生成签名。
2.在提出请求时包括签名，oauth参数 3.服务器通过再次生成签名来验证请求，除非在这种情况下它使用与密钥对应的SECRET

我认为这样我几乎可以确认REST原则。据我所知，服务器是无定形的。

以这种方式做事的利弊是什么？

Answer 1

如果“安全性是一个问题”，那么我会说你使用开放标准和库来实现你想要的东西要好得多。这样做的主要原因是，如果你自己这样做，你很可能会忘记一些事情;这些标准有很多眼睛看着它们，寻找漏洞。

您的选择包括（复杂程度越来越高）

基本身份验证和HTTPS

所有内容都是加密的，这使得它无法压缩或查看，它会在服务器上使用更多的功能，甚至更多可能是客户端上的电池电量，从而增加了开销。易于实现，因为它得到了图书馆的良好支持。

摘要式身份验证

未加密的邮件通过网络传输，但是在授权标头中安全地管理了身份验证。有关详细信息，请参阅wikipedia entry。

的OAuth

了解Google如何为已安装的应用提供OAuth。我相信这不是你想要的，因为你不是要求在应用程序之间共享数据，只是对用户进行身份验证。

滚动你自己的

如果您想自己动手，我建议您查看例如谷歌（现已弃用？）ClientLogin曾经如何运作。

1. 客户端将获取受保护的资源，并获得401指示以执行GoogleLogin身份验证，包括用于在何处执行登录的URI
2. 客户端（知道如何执行此操作）以特定方式将请求发布到该URI
3. 服务器以特定响应进行响应，包括（长）令牌
4. 客户端现在可以使用该令牌对受保护资源执行GET请求。

无国籍

您引用REST，它规定请求不应特别依赖于先前的交互：“...从客户端到服务器的每个请求必须包含理解请求所需的所有信息，并且不能利用任何存储的上下文服务器。” （fielding）这意味着服务器不应在表中存储会话上下文（如身份验证令牌）。

解决这个问题的一种方法是使用任何基于令牌的方法（服务器告诉客户端有关它应该用于未来请求的令牌），其中令牌不是随机数，而是发送给服务器本身的消息。为了保护自己免受客户端的篡改，可以对其进行签名，如果您害怕客户查看它，您可以加密它。

编辑虽然我不确定，Google似乎不太可能拥有所有已发布的所有身份验证令牌的表格;令牌的长度表明令牌是一些加密的消息，证明持有此令牌的人实际上在某个时间段提供了真实的凭证。

Answer 2

OAuth完全按照标准方式执行。

Answer 3

您可以使用HTTPS和HTTP Basic Auth的组合。两者都是现有标准，并且在一起使用时应该足够安全。