【发布时间】：2012-09-05 13:43:22
【问题描述】：
这主要是措辞问题。但尽管这是一个非常重要的问题，它可能会导致对更大团队维护的大型代码库的误解。假设我们有一个带有身份验证系统的非常基本的 CRUD/RESTful 应用程序。在这种情况下，尝试完成数据更改请求（POST/PUT）的经过身份验证的用户将被服务器识别（身份验证），然后检查该识别用户是否有权创建/更新资源问题（授权）。
现在假设我将实现 Oauth 协议以在稍后阶段支持某种 Web API 解决方案。在这种情况下，来自客户端应用程序 A 的用户必须向资源提供者请求 授权 才能执行某些操作。
所以到目前为止，我们在同一个应用程序中有两个有效的授权概念。在应用程序级别这不是什么大问题，因为我们可以将这两个概念包含在相关的命名空间中，但在数据库中，我有两个有效的候选者 不能 共享名称 authorizations 。
由于我不是命名空间表名称的忠实拥护者，因此我想就可能重命名其中一个表名（或者您可能已经实施的其他一些疯狂的解决方案）提出建议。
欢呼
【问题讨论】：
-
为什么 OAuth 授权和服务器授权不能只是一个单独的 DB 表？
-
OAuth 授权授予外部应用程序授权的外部用户对主应用程序中资源所有者的资源执行任何操作。服务器授权授予主应用程序授权的用户对地图应用程序中的资源执行任何操作。
-
因此，除了处理所有 Oauth 协议内容之外，Oauth 授权还与它所指的客户端应用程序耦合。 “简单”授权只是对主应用程序上某些操作的过滤（例如检查用户是否有权编辑资源）。将它们放在同一个表中有点过分，因为“简单”授权不需要 Oauth 授权要求的很多内容。
标签： web-applications oauth authorization oauth-2.0 crud