【问题标题】:How does OAuth handle authorization?OAuth 如何处理授权?
【发布时间】:2014-10-13 16:39:16
【问题描述】:

我们已经使用 RestEasy 实现了一个 RESTful API。现在我们正计划构建自己的 OAuth 实现并将其与我们的 Rest API 集成。

我不完全了解 OAuth 如何处理对 API 的每个请求的授权。我的理解如下:

  1. 在进行任何 REST API 调用之前,OAuth 服务器对用户进行身份验证。
  2. 每个 REST API 调用都将包含一个令牌。 REST API 服务器使用 OAuth 服务器验证此令牌。如果令牌有效,则服务器将返回响应。

这应该会对性能产生影响,因为我们正在使用第二个服务器验证每个 API 请求的令牌。这种理解正确吗?

【问题讨论】:

  • 不要。真的。如果您不了解 OAuth 并在安全领域生活和呼吸,那么您将把它搞砸。正确地进行身份验证是困难的。找到您可以接受的供应商实施。

标签: performance rest architecture oauth-2.0


【解决方案1】:

这取决于您将如何定义 REST API。基本上 OAUTH 调用具有以下组件。

用户:谁提出请求。

提供者:谁持有用户信息并提供访问它们的api。

消费者:谁要求用户授权消费者向api发出请求。

基本工作流程如下,

  1. 用户尝试从消费者访问受限资源。

  2. 消费者要求用户分享一些关于他的信息。(范围)

  3. 用户选择他的身份提供者。

  4. 消费者应该是提供者知道的。(通常消费者将自己注册为提供者门户中的应用程序/网站)

  5. 消费者使用其 consumer_key 和范围重定向到提供者。

  6. 用户授权应用程序并授予对其某些资源的访问权限。

  7. 提供者创建一个令牌并重定向回消费者。

  8. 消费者交换此令牌及其身份以获得用户的 access_token。

  9. 消费者使用 access_token 向提供者发出授权请求,并询问有关用户的少量信息。

  10. 提供者将这些信息发送给消费者。

  11. 消费者验证信息,用户登录系统。

现在每个令牌都是针对范围生成的,并且将在几天内有效。令牌验证将成为 Provider 响应的一部分。

在您的系统中,您可以根据令牌存储用户数据,这样我们就不需要请求 Provider 发送这些信息。但是如果你不想存储用户信息肯定会有额外的调用。

【讨论】:

  • 如果我根据令牌存储用户数据,我需要处理会话超时和令牌撤销。我们是否可以将类似 memcache 的数据源附加到 Oauth 服务器,以便我们可以提高会话验证性能。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2016-05-30
  • 1970-01-01
  • 2018-11-21
  • 2016-05-28
  • 2012-03-22
  • 2019-06-20
  • 2014-07-05
相关资源
最近更新 更多