针对Web应用程序和移动应用程序的REST API身份验证 [英] REST API authentication for web app and mobile app

问题描述

我在决定如何为RESTful API实施身份验证时遇到一些麻烦，这种身份验证对于Web应用程序和移动应用程序都可以安全使用.

I'm having some trouble deciding how to implement authentication for a RESTful API that will be secure for consumption by both a web app and a mobile app.

首先，我认为可以选择通过HTTPS进行HTTP基本身份验证.这对于移动应用程序非常适用，因为用户名和密码可以安全地存储在操作系统钥匙串中，并且在传输过程中不会被拦截，因为请求将通过HTTPS进行.对于API来说也很优雅，因为它完全是无状态的.这个问题是针对网络应用的.将无法使用这种钥匙串来存储用户名和密码，因此我需要使用Cookie或localStorage，但随后会将用户的私人详细信息存储在易于访问的位置.

Firstly, I thought to investigate HTTP Basic Authentication over HTTPS as an option. It would work well for a mobile app, where the username and password could be stored in the OS keychain securely and couldn't be intercepted in transit since the request would be over HTTPS. It's also elegant for the API since it'll be completely stateless. The problem with this is for the web app. There won't be access to such a keychain for storing the username and password, so I would need to use a cookie or localStorage, but then I'm storing the user's private details in a readily accessible place.

经过更多研究，我发现了很多有关HMAC身份验证的话题.我看到的这种方法的问题是，需要有一个只有客户端和服务器才知道的共享机密.除非我有一个api/login终结点，该终结点使用用户名/密码并将该机密返回给cookie，否则如何才能将此每个用户的机密传递给Web应用程序中的特定用户?在将来的请求中使用.但是，这是向API引入状态.

After more research, I found a lot of talk about HMAC authentication. The problem I see with this approach is there needs to be a shared secret that only the client and server knows. How can I get this per-user secret to a particular user in the web app, unless I have an api/login endpoint which takes username/password and gives the secret back to store in a cookie? to use in future requests. This is introducing state to the API however.

为了让其他扳手投入工作，我希望能够将API限制为某些应用程序(或者能够阻止某些应用程序使用该API).我看不到完全公开该Web应用程序是怎么可能的.

To throw another spanner into the works, I'd like to be able to restrict the API to certain applications (or, to be able to block certain apps from using the API). I can't see how this would be possible with the web app being completely public.

我真的不想实现OAuth.对于我的需求来说，这可能是过分的了.

I don't really want to implement OAuth. It's probably overkill for my needs.

我觉得我可能还没有完全理解HMAC，所以我欢迎您进行解释，以及如何通过Web应用程序和移动应用程序安全地实施HMAC.

I feel as though I might not be understanding HMAC fully, so I'd welcome an explanation and how I could implement it securely with a web app and a mobile app.

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

I ended up using HTTP Basic Auth, however instead of providing the actual username and password every request, an endpoint was implemented to exchange the username and password for an access key which is then provided for every authenticated request. Eliminates the problem of storing the username and password in the browser, but of course you could still fish out the token if you had access to the machine and use it. In hindsight, I would probably have looked at OAuth further, but it's pretty complicated for beginners.

推荐答案

您应使用OAuth2.方法如下:

You should use OAuth2. Here is how:

1)移动应用

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

The mobile app store client credentials as you state yourself. It then uses "Resource Owner Password Credentials Grant" (see http://tools.ietf.org/html/rfc6749#section-4.3) to send those credentials. In turn it gets a (bearer) token it can use in the following requests.

2)网站

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

The website uses "Authorization Code Grant" (see http://tools.ietf.org/html/rfc6749#section-4.1):

1. 网站会看到未经授权的请求，并将浏览器重定向到REST API中启用HTML的自动化终结点.

1. Website sees unauthorized request and redirects browser to HTML-enabled autorization endpoint in the REST api.

用户通过REST服务进行身份验证

User authenticates with REST service

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

REST site redirects user back to website with access token in URL.

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

Website calls REST site and swaps access token to authorization token.

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

Here after the website uses the authorization token for accessing the REST service (on behalf of the end-user) - usually by including the token as a "bearer" token in the HTTP Authorization header.

这不是火箭科学，但要完全理解还需要一些时间.

It is not rocket science but it does take some time to understand completely.

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

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

In OAuth2 each client is issued a client ID and client secret (here "client" is your mobile app or website). The client must send these credentials when authorizing. Your REST service can use this to validate the calling client

这篇关于针对Web应用程序和移动应用程序的REST API身份验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！