针对Web应用和移动应用的REST API身份验证

mak*_*knz 52 authentication api rest

我在决定如何为RESTful API实现身份验证时遇到一些麻烦,这些API对于Web应用程序和移动应用程序都是安全的.

首先,我考虑通过HTTPS调查HTTP基本身份验证作为选项.它适用于移动应用程序,其中用户名和密码可以安全地存储在操作系统密钥链中,并且由于请求将通过HTTPS而无法在传输过程中被截获.API也很优雅,因为它完全是无状态的.这个问题是针对Web应用程序的.将无法访问用于存储用户名和密码的密钥链,因此我需要使用cookie或localStorage,但随后我将用户的私人详细信息存储在易于访问的位置.

经过更多的研究,我发现了很多关于HMAC认证的讨论.我用这种方法看到的问题是需要一个只有客户端和服务器知道的共享秘密.如何在Web应用程序中为特定用户获取每个用户的秘密,除非我有一个api/login端点,它接受用户名/密码并将秘密返回存储在cookie中?在将来的请求中使用.然而,这是向API引入状态.

为了让另一个扳手投入工作,我希望能够将API限制为某些应用程序(或者,能够阻止某些应用程序使用API​​).我无法看到这个网络应用完全公开的可行性.

我真的不想实现OAuth.这可能对我的需求有些过分.

我觉得好像我可能没有完全理解HMAC,所以我欢迎一个解释,以及如何通过网络应用程序和移动应用程序安全地实现它.

更新

我最终使用HTTP Basic Auth,但是不是每次请求都提供实际的用户名和密码,而是实现端点以交换访问密钥的用户名和密码,然后为每个经过身份验证的请求提供访问密钥.消除了在浏览器中存储用户名和密码的问题,但当然如果您有权访问该计算机并使用它,您仍然可以删除令牌.事后看来,我可能会进一步研究OAuth,但对初学者来说这很复杂.

Jør*_*ldt 24

你应该使用OAuth2.方法如下:

1)移动应用程序

您自己陈述的移动应用程序存储客户端凭据.然后,它使用"资源所有者密码凭据授权"(请参阅http://tools.ietf.org/html/rfc6749#section-4.3)发送这些凭据.反过来,它获得了可以在以下请求中使用的(承载)令牌.

2)网站

该网站使用"授权代码授权"(见http://tools.ietf.org/html/rfc6749#section-4.1):

  1. 网站看到未经授权的请求,并将浏览器重定向到REST API中支持HTML的自动化端点.

  2. 用户使用REST服务进行身份验证

  3. REST站点使用URL中的访问令牌将用户重定向回网站.

  4. 网站调用REST站点并将访问令牌交换为授权令牌.

此后,网站使用授权令牌访问REST服务(代表最终用户) - 通常通过在HTTP授权标头中将令牌作为"承载"令牌包含在内.

这不是火箭科学,但确实需要一些时间来完全理解.

3)限制某些应用程序的API访问

在OAuth2中,每个客户端都会获得一个客户端ID和客户端密钥(此处"客户端"是您的移动应用程序或网站).客户端必须在授权时发送这些凭据.您的REST服务可以使用它来验证调用客户端

  • 客户如何保密网络应用程序?源代码对所有人开放,是什么阻止某人窃取它与未经授权的应用程序一起使用? (4认同)