2

我正在考虑一种我不确定 OAuth 是否适合的设计，但这是基本问题。

我有需要不同安全级别的企业网络服务。

  1. 检查用户的成绩 - 需要用户名/密码
  2. 更改用户等级 - 需要用户名/密码/RSA 令牌号

因此，如果应用程序想要执行 (1)，它将要求提供凭据，但是，我希望 OAuth 服务器被告知用户正在尝试访问哪个服务，并且将显示正确的字段，如这是初始登录。

现在，第二次，应用程序（浏览器或应用程序）有一个令牌，但是，这个令牌是不够的，但是，应用程序不应该知道这一点，因为安全要求可能会根据安全人员的决定而改变是合适的。

因此，当提供令牌以到达 (2) 时，它确定它还不够，因此返回错误，因此应用程序可以去尝试获取新令牌。

我还没有实现任何这些，但作为一个基本设计，我不确定 OAuth 是否适合我想做的事情，或者我是否最好编写自己的身份验证系统。

最初，Web 服务的客户端将是移动 Web 应用程序，但是，我想让它足够灵活，这样当我们编写本地手机应用程序时，它就能够使用相同的系统。因此，让应用程序需要知道我遇到问题的安全性，并且每次都将凭据传递给我不满意的 web 服务，所以我希望有一个可以使用的加密令牌，如果你满足要求对于（2），那么您可以使用相同的令牌进入（1）。

那么，OAuth 是否适合这种情况？

基于此（https://developers.google.com/accounts/docs/OAuth2InstalledApp），OAuth确实具有身份验证方面。

更新： - 看来 Open Connect ( http://openid.net/connect/ ) 在这方面可能比 OAuth 更好，但我现在只是在学习 Open Connect。

4

1 回答 1

1

在我看来，使用 oAuth 有两个好处……

  1. 用户无需为您的服务创建新的用户名/密码。
  2. 您不需要存储密码或拥有用于登录的 ssl 证书（也许您需要 ssl 用于其他事情，不确定）。

你提到你有两个服务。您不希望用户必须同时登录两者，因此我建议创建一个用户登录的外观（Web 服务）（使用 oAuth），因为您需要配置一个回调 url。通过该外观服务，您可以授权某些调用并将这些调用转发给其他服务。

我不确定用户Kos是什么意思，但 oAuth 用于身份验证，而不是用于在您的应用中授权（我相信）。您需要将 oAuth 用户与该用户的内部表示以及访问权限一起映射。这仍然意味着您需要将用户存储在您身边的某个地方。唯一的事情是您不需要存储密码，也不需要开发自定义登录页面。

所以简而言之，oAuth 只能告诉你某个用户是已知的并且是经过身份验证的。剩下的就看你了。实施 oAuth 并不难，但也不是微不足道的。所以这让我们回到了我之前提到的两个好处，你必须决定是否以及为什么要走这条路。

于 2012-07-05T14:03:52.203 回答