2

我正在开发一个 API，并考虑使用 OAuth（3-legged 方法）进行身份验证和授权。

这是基本思想：

  • 为了让客户端（移动应用程序或网络应用程序）使用此 RESTful API，用户必须使用身份提供商/服务器（例如 Google、Facebook 等）登录

基本上 3 方将在这里互动：

  • 移动/网络应用程序：尝试访问我的 API 的应用程序
  • API：包含应用程序运行数据的站点
  • 身份服务器：允许用户登录以访问 API 的站点

现在，我理解这个过程的方式（假设我这样做）。这将是流程（总结）：

  • 用户将尝试从 API（消费者）访问数据；
  • 消费者发现用户没有登录；
  • 用户获得一个页面（带有服务提供商按钮，例如使用 Google 登录）；
  • 用户点击按钮，服务提供者返回登录表单；
  • 用户登录；
  • 服务提供者返回请求特定权限的页面；
  • 用户授予权限；
  • 服务提供者返回一个访问令牌给用户；
  • 用户使用访问令牌再次尝试向消费者（API）发出请求；
  • 消费者获取令牌并针对服务提供者进行验证；
  • 消费者授予用户访问权限。

第一的

这个过程是正确的（在更高的层次上），还是我完全误解了整个事情。如果不正确：您能提供一些调整吗？

第二

在这整个过程之后。消费者如何与用户沟通？我是否必须在发出的每个请求（在移动应用程序和 API 之间）传递一个令牌？或者我可以只使用服务提供商的用户详细信息来识别用户吗？

第三

消费者 (API) 究竟如何针对服务器验证用户提供的令牌？这是否已经在 OAuth 中实现，还是我必须自己做？

第四和最后

在实现方面，客户端（移动应用程序/网络应用程序）和消费者（API）之间有什么区别？

我是新手，我正在尝试在 PHP（API）中实现它。如果您对 PHP 代码（示例实现）或外部资源有任何引用，我将不胜感激 :-)

4

1 回答 1

1

我也是 oauth 的新手，但我会尽力提供帮助。首先，您可以在此处查找可以提供帮助的适当库。

至于我，你的 oauth 流程是正确的。你也可以在这里找到一个很好的解释。请记住，授权服务器应返回用于获取访问令牌的授权代码。

所以你的问题：

1）点击第二个链接 - “授权码”。

2) 对于您的 API 的每个请求，您都应该发送您的访问令牌。就像是

http://<your api>?access_token=7f813af1-381d-4dd7-b70b-b6a8399b2c00

3）只需使用第一个链接中的库。我希望他们已经实施了这一点。:)

4）不能完全理解你的意思。您的客户端必须能够获取访问令牌、存储它并通过请求发送它。您的 API 服务器必须能够从客户端接收访问令牌，如果访问令牌正确，则授予对 api 的访问权限。

于 2013-02-20T09:12:35.207 回答