如何在RESTful API中实现两级身份验证? [英] How to implement two level authentication in a RESTful API?

问题描述

我正在为一个相当复杂的Web应用程序(进一步称为api.mywebapp.com)编写RESTful API

I am writing a RESTful API for a fairly complex web application (further referred as api.mywebapp.com)

要求包括api.mywebapp.com应该处理:

The requirements include that api.mywebapp.com should handle:

• API级身份验证(授权客户端应用程序，例如:移动 应用程序)
• 用户级别身份验证(授权www.mywebapp.com 注册用户，以便他们可以访问其受保护的资源)

• API level authentication (authorizing client application eg.: mobile app)
• User level authentication (authorizing www.mywebapp.com registered users so they can access their protected resources)

用法示例:

1. 移动应用程序通过以下方式连接到 https://api.mywebapp.com 有效的基本HTTP授权标头(授权:基本 [base64_encoded_username:password])

1. Mobile application connects to the https://api.mywebapp.com with a valid basic HTTP authorization header (Authorization: Basic [base64_encoded_username:password])

api.mywebapp.com对移动应用进行身份验证，并在身份验证成功后会使用生成的令牌响应请求.

api.mywebapp.com authenticates mobile app and on successful authentication it responds to the request with a generated token.

移动应用程序现在在所有连续的时间内都使用接收到的令牌 请求它. (api.mywebapp.com还限制了经过身份验证的移动应用程序可以执行的API操作，例如:它无法使用系统管理员级别的API控制器)

Mobile app is now using the received token in all consecutive requests it makes. (api.mywebapp.com also limits the API operations that the authenticated mobile app can do eg.: it cannot use system admin level API controllers)

移动应用程序进入一种状态，需要登录www.mywebapp.com用户才能访问并显示受保护的资源.

Mobile app gets to a state where it needs to login a www.mywebapp.com user to access and show a protected resource.

这是我不确定应该怎么做的地方.

This is where I am not sure how this should be done.

api.mywebapp.com是否也应通过用户登录的基本HTTP身份验证来挑战移动应用程序?如果是这样，那么如何使用API​​级别的当前身份验证来解决呢?

Should api.mywebapp.com challenge mobile app with basic HTTP authentication for the user login too? If so, how would that work out with the current authentication already in place for API level?

我使用生成的令牌的原因是: www.mywebapp.com是由会话驱动的，令牌也可以用作会话"标识符(会话也已替换为某些服务器端存储)

My reason for using a generated token is: www.mywebapp.com is very session driven and a token also functions as a "session" identifier (session is also replaced to some server-side storage)

所以我面临两个单独的问题(这个问题实际上是关于第一个问题):

So I am facing two separate issues (this question is really about the first one):

• 如何使用REST API进行多级身份验证?

• How to multi level authenticate with a REST API?

如何为会话驱动的Web应用程序实现真正的RESTful API，而无需对应用程序本身进行重大更改?我发现此问题很重要，因为在RESTful API中，客户端状态不能存储在服务器上.

How to implement a truly RESTful API for a very session driven web application without major changes in the application itself? I found this issue important because in a RESTful API the client state must not be stored on the server.

推荐答案

这几乎与OAuth2资源所有者密码凭据授予"相同: http://tools.ietf.org/html/rfc6749#section-4.3 .在授权标头中设置客户端凭据，并将用户凭据发布为x-www-form-url-encoded正文.结果可能是您已经在使用的承载/会话令牌.

This is almost identical to OAuth2 "Resource Owner Password Credentials Grant": http://tools.ietf.org/html/rfc6749#section-4.3. Set client credentials in Authorization header and post user credentials as x-www-form-url-encoded body. The result can be a bearer/session token as you already use it.

是的，会话有点问题，因为会话需要服务器存储某种客户端状态.您可以改为返回带有用户名和密码的承载令牌，并带有某种数字签名，以使客户端无法对其进行更改. OAuth2非常明确地表示不对承载令牌的格式进行任何说明.

And, yes, sessions are a slightly problematic since they require the server to store some sort of client state. You can instead return a bearer token that embeds username+password in it with some kind of digital signing such that the clients cannot change it. OAuth2 is very explicit about not saying anything about the format of bearer tokens.

这篇关于如何在RESTful API中实现两级身份验证?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！