Web应用程序和Web服务的身份验证

时间:2011-01-12 18:59:13

标签: web-services web-applications authentication https

我目前正在开发一个包含Web应用程序和客户端软件的应用程序。客户端通过webservices进行通信,支持SOAP和Protobuffer实现。

初始注册是通过webapplication完成的,后者依赖于用户名+密码验证。

完成注册过程后,所有功能也可通过客户端获得,客户端只能通过HTTPS进行通信。为了验证Web服务调用,我目前正在考虑三种可能的方法:

  1. 在每封邮件中包含用户名和密码。但是,即使通过HTTPS保护,在每个请求中包含凭据是否真的是一种很好的做法?

  2. 在第一个Web服务请求中提供用户名和密码。然后,客户端获取一个用于将来所有请求的令牌。 (注意:强制用户将服务器生成的令牌复制到客户端应用程序是不可接受的。)只有当用户撤销令牌时,他才需要再次发送用户名和密码才能获得新令牌。这种基于令牌的方法似乎很常见,例如Google,AWS和Rackspace都在使用它们。但在这种情况下,它真的得到了回报吗?

  3. 在客户端上散列密码听起来像是一个很好的解决方案。但是,我想在服务器端加密加密的密码。添加仅用于获取盐的请求听起来不是最佳解决方案,还是它?

  4. 是否有最佳做法或提示?我找不到太多关于这些要求的信息。 目前我会选择2),但我还不确定。

    该项目基于Java,Apache CXF,Protobuffers和Shiro,但不应对一般问题产生太大影响......

1 个答案:

答案 0 :(得分:1)

如果您只关注身份验证,既不是保密也不是诚信,您可以通过以下方式处理:

  • HTTP传输级别,使用HTTP BasicAuth(每条消息上的用户+密码)+最终用于保密的HTTPS,但是正如您注意到的(解决方案1)它是一种旧学校并且将用户/密码保留在本地缓存中不是很重要,但无法建议。
  • 使用安全令牌的消息级别(soap消息),但我不知道Protobuffer
  • 应用程序级别(解决方案2和3),这就是Google,Amazon,Ebay和其他人的工作方式。您不会要求用户复制/粘贴其令牌,您将从用户/密码生成一个

我会使用令牌来保护应用程序级别,因为从服务器获取salt几乎就像获取令牌并且不会增加更多安全性(只有您才知道安全盐,如果通道受到保护则意味着从给定的密码和用户名获取令牌也是安全的。)

更好但更复杂的解决方案是使用SSL证书,可在浏览器和客户端软件中使用。

相关问题