我正在为一个相当复杂的Web应用程序编写一个RESTful API（进一步称为api.mywebapp.com）
要求包括api.mywebapp.com应该处理：
用法示例：
移动应用程序使用a连接到https://api.mywebapp.com 有效的基本HTTP授权标头（授权：基本 [base64_encoded_username：密码]）
api.mywebapp.com对移动应用进行身份验证，成功验证后，它会使用生成的令牌响应请求。
移动应用现在正在连续使用收到的令牌 要求它。 （api.mywebapp.com还限制经过身份验证的移动应用程序可以执行的API操作，例如：它无法使用系统管理员级API控制器）
移动应用程序进入需要登录www.mywebapp.com用户才能访问并显示受保护资源的状态。
这是我不确定应该怎么做的地方。
api.mywebapp.com是否应该通过基本HTTP身份验证为用户登录挑战移动应用？如果是这样，那么对于API级别，当前的身份验证将如何解决？
我使用生成令牌的原因是： www.mywebapp.com是非常会话驱动的，令牌也可以作为“会话”标识符（会话也被替换为某些服务器端存储）
所以我面临两个不同的问题（这个问题实际上是关于第一个问题）：
如何使用REST API进行多级身份验证？
如何为会话驱动的Web应用程序实现真正的RESTful API而不会对应用程序本身进行重大更改？我发现此问题很重要，因为在RESTful API中，客户端状态不得存储在服务器上。
答案 0 :(得分：2)
这几乎与OAuth2“资源所有者密码凭据授权”相同：http://tools.ietf.org/html/rfc6749#section-4.3。在Authorization标头中设置客户端凭据，并将用户凭据发布为x-www-form-url-encoded body。您已使用它的结果可以是承载/会话令牌。
而且，是的，会话有点问题，因为它们要求服务器存储某种客户端状态。您可以使用某种数字签名返回在其中嵌入用户名+密码的持票人令牌，以便客户端无法更改它。 OAuth2非常明确地没有说明有关承载令牌的格式。