我正在研究通过HTTP公开的API,这些API将由合作伙伴公司使用并部署到他们众多的客户端。保护HTTP API - 没有用户密码提示并避免公开私钥
在某些情况下,客户端将基于浏览器。这是我的主要关注点,但我可能会在客户端是Windows应用程序的情况下应用相同的模式。我认为,当它是一个Windows应用程序而不是基于浏览器的应用程序时,在客户端上获得私钥的范围更大。所以发生的通信来自合作伙伴应用程序呈现给我们的服务器的浏览器页面,我们托管我们的API。
底线是我们不能提示最终用户输入凭证,并且必须依靠每个请求都会传递的存储密码/密钥/令牌。我担心的是,我想阻止合作伙伴公司将此令牌烘焙成客户端代码。以下是场景的高级描述。
- 合作伙伴建立与我们(手动过程)的账户,进行了必要的开发工作,以消耗他们的产品的API,然后滚出来给他们的客户。
- 然后客户运行产品并通过向导建立他们的账户。我们可以在这时提示他们输入用户名和密码,但是以后对API的所有请求都不应该提示实际最终用户输入凭据。
- 然后,他们执行许多业务流程,在许多不同的用户环境下在许多工作站上调用我们的API。我们不关心个人用户信息。
对于我将跳过步骤1,注重执行步骤2和3
我目前的工作,以确保该API,并想出了下面的这个问题的目的设计:
- HTTPS到处(所有请求使用SSL/TLS)
- 所有POST请求利用CSRF令牌
- 在步骤2中,当客户端创建的我们为他们提供了一个客户端身份验证码。合作伙伴应该编写他们的应用程序来存储这个授权码到服务器上。
- 在未来调用我们的API之前,他们调用我们的JavaScript库上的Init函数并提供回调,如“GetAuthToken”。
- 在每次调用我们的API时,我们检查我们是否有Auth令牌(在服务器上),如果没有,我们会返回一个错误并调用回调。
- 执行回调时,合作伙伴应该使用HTTPS调用其服务器来检索令牌。这个请求将受到他们的正常认证,所以假设如果用户在他们的系统中被认证,那么他们可以检索认证令牌。
- 我们收到验证令牌,调用我们的服务器来验证它,然后设置一个包含令牌的HTTPOnly cookie。
- 当cookie过期时,我们再次调用GetAuthToken回调函数。
- 跨域问题正在使用的postMessage
- 我们可以使身份验证令牌撤销
我们必须联合安全的形式在这里,如果用户与当时的合作伙伴认证,我们假定他们有权访问管理我们的API。我认为避免将私钥/授权令牌烧入客户端代码的唯一方法就是这种回调机制。
我是否过于复杂?还有其他更简单的方法吗?我意识到,如果任一站点对XSS开放或受到恶意软件攻击,所有赌注都将关闭,但至少不会将私钥转换为javascript或标记,用户无法右键单击查看源并将所有私钥告诉所有人。
编辑:发现这个问题。最佳答案描述了类似于我所描述的内容,但提到WIF,我不想强迫合作伙伴实施(他们甚至可能不会运行Windows)。还是想对我的做法,虽然反馈...
Web Application - User Authentication Across Domains
您可以添加有关客户端上下文的详细信息 - 服务器服务器还是浏览器到服务器?听起来像浏览器,但要确保。 – hoserdude 2012-03-07 19:48:01
@hoserdude - 谢谢,我添加了一些关于客户背景的说明。这是浏览器,我主要关心的服务器。 – tidmutt 2012-03-07 19:52:31