【发布时间】：2013-02-14 17:52:32
【问题描述】：
很多关于 RESTful Web Services 的例子都没有考虑到当今许多应用程序都是多用户的问题。
想象一个暴露 RESTful API 的多用户后端。后端数据架构使用共享数据库和共享模式。每个表都将包含对tenant_id 的引用：
+-------------+----+-----------------+
| tenant_name| id | shared_secret |
+-------------+----+-----------------+
| bob | 1 | 2737sm45sx543 |
+-------------+----+-----------------+
| alice | 2 | 2190sl39sa8da |
+-------------+----+-----------------+
+-------------+----+-------+-----------+
| pet_name | id | type | tenant_id |
+-------------+----+-------+-----------+
| fuffy | 1 | dog | 1 |
+-------------+----+-------+-----------+
| kerry | 2 | cat | 2 |
+-------------+----+-------+-----------+
问题 1：三个或更多客户端应用程序（即 Android、iOS 和 Web App）与 RESTful 后端交互，您将如何针对后端执行身份验证？
RESTful backend, API, HTTP-Verbs, shared database and schema
|
|
+---- Web Application (Client 1)
| |
| + Alice
| |
| + Bob
|
+---- Android Application (Client 2)
| |
| + Alice
| |
| + Bob
|
+---- iOS Application (Client 3)
| |
| + Alice
| |
| + Bob
|
每个客户都应该允许 Alice 和 Bob 管理她/他的宠物。每个客户端都是一个 GUI，它将使用（在内部，发出 HTTP 请求）后端。问题：每个客户端如何才能对后端进行身份验证？
假设 HMAC（完全是 RESTful，没有会话）：此方法涉及使用共享密钥对有效负载进行签名（从不通过网络发送）。每个客户端是否应该拥有自己的tenant 表副本（其中包含shared_secret 字段）？
Android App -> Client Sign -> Signed Request -> Backend -> Result
Web App -> Client Sign -> Signed Request -> Backend -> Result
问题 2：资源 URI 应该是什么样的？
以下是获取 Bob 宠物的两种可能性：
可能性 #1：Authorization 标头为您提供租户的（唯一）名称：
GET /pets HTTP/1.1
Host: www.example.org
Authorization: bob:c29kYW9kYSBhb2lzYWRoIGYgZDUzNDUz
可能性 #2。 tenant_id 作为查询参数发送：
GET /pets/tenant_id=1 HTTP/1.1
Host: www.example.org
Authorization: bob:c29kYW9kYSBhb2lzYWRoIGYgZDUzNDUz
【问题讨论】：
-
小心使用短语多租户。我不相信它意味着你认为它的作用。在此处查看详细信息msdn.microsoft.com/en-us/library/aa479086.aspx
-
@Gaz_Edge 这意味着在客户端之间虚拟分区数据，并且单个实例将为更多客户端提供服务，这就是我正在做的事情。你同意吗？
-
我认为你过于复杂了。您有 1 个 Web 服务、n 个 Web 服务客户端和 x 个用户，是吗？
-
@Gaz_Edge 完全正确。你会怎么简化呢？
-
我在回答中提供了一个简单的方法。你觉得我的回答不会给你你想要的吗？如果是这样，请解释一下，我会尽力提供帮助。
标签： web-services api rest authorization restful-authentication