当资源和认证服务器相同时如何实现 OAuth答案

【问题标题】：How to implement OAuth when the resource and auth servers are same当资源和认证服务器相同时如何实现 OAuth
【发布时间】：2019-08-10 21:36:26
【问题描述】：

我有一个带有 JWT 身份验证的 Django Rest API，它是 Angular 前端的后端。有许多客户在我们的前端使用该服务。现在一些企业客户希望从他们的系统后端集成 API。我不想从当前的 API 中删除 JWT。我计划在相同的后端中为这些用户使用 OAuth 令牌创建新的 API。

我想知道在这种情况下实施 OAuth 的最佳方式是什么。

我认为客户凭证授予类型是最好的方法。

问题 1：我是否认为客户端凭据是正确的方法？

对于那些企业用户，他们只需通过 UI 界面获得访问令牌，这样他们就可以访问我们所有的 API。但这里的问题是首先获取客户端 ID 和客户端密码并使用它来获取访问令牌的额外步骤。

问题 2：client ID 和 client secret 有什么用？

问题3：我的后端是否应该隐藏生成客户端 ID 和客户端密码的过程，只提供访问令牌（或）给他们客户端 ID 和客户端密码，然后要求生成访问令牌？

问题 4：如果我向他们提供没有客户端 ID 和机密的访问令牌，是否可以无限期到期？和

TLDR; 资源服务器和认证服务器相同时如何实现OAuth？

【问题讨论】：

@Ashwin 我遇到了同样的问题。你是怎么解决这个问题的？

标签： django oauth oauth-2.0 django-oauth

【解决方案1】：

authorization codegrant 或implicitgrant 可能更适合这种情况。第一个允许您在将令牌返回给用户之前添加一个身份验证步骤（如果您也想将 JWT 身份验证集成到此，这可能很有用），第二个主要用于单页应用程序，并且确实不包括中间认证步骤。如果您想提高效率，这将非常有用。
client_id 和 client_secret 在您在身份提供者（授权服务器）中注册客户端应用程序时提供给您。此客户端应用程序并不意味着属于您的客户端的应用程序或 API，而是您计划合并 OAuth（和 OIDC）的您自己的应用程序。这两个参数在发出授权请求以获取令牌时很有用。服务器使用这些值来确定请求是否由有效的应用程序发出。只有您可以访问这些值，因为您将是向服务器注册应用程序的人。
我认为这个问题在上一节中已经得到解答。

我认为最好在执行任何实施之前通过this。它提供了您在实施 OAuth 系统之前应具备的大部分基本知识。我希望这个答案对你有用。

【讨论】：

正如我所读到的，授权代码授予需要重定向 URL 和其他东西，在我的方法中，我只需要将 API 令牌直接提供给用户。同样在我的情况下，我的服务器既是授权服务器又是资源服务器。我只需要给我的客户一些令牌，以便他可以访问我的 API。在这种情况下，如果我的客户的访问令牌过期会发生什么
你可以试试refresh tokens。它们允许用户在前一个访问令牌过期时获得新的访问令牌，而无需要求用户重新认证或授权。如果这也过期了，您必须为用户提供新的令牌。如果您不想一直处理令牌过期，请将令牌的持续时间设置为较大的值，以便它们不会轻易过期（但不推荐）。

【解决方案2】：

问题 1：我认为客户端凭据是正确的方法吗？

是的。提供新的 API 不需要在最终用户的上下文中调用。

问题 2：client ID 和 client secret 有什么用？

客户端 ID 允许身份验证服务器识别应用程序请求令牌（它通常被传递到访问令牌也允许 API 识别调用应用程序）。
客户端密钥意味着认证服务器可以信任客户端是真正他说他是谁，因为只有他应该有私人客户他的公共客户 ID 的秘密。

在这种情况下，它实际上是用户名和密码。

问题3：我的后端是否应该隐藏生成客户端ID的过程和客户端密码，只需提供访问令牌（或）给他们客户端 ID 和Client Secret，然后要求生成访问令牌？

您的身份验证服务器应向应用程序发出一次客户端凭据，并且应用程序应在每次希望通过客户端凭据授予类型获取令牌时提供这些凭据。

【讨论】：

【解决方案3】：

oAuth2 中有 4 种授权类型，适用于不同的场景。

客户端凭据：消费者（应用程序）使用使用 apikey（或 clientId）创建的不记名令牌和仅机密调用后端。主要用于检索通用信息的匿名调用。

资源所有者密码凭证 (ROPC)：消费者（应用程序）使用使用 apikey、secret、用户名和密码创建的不记名令牌进行调用。主要在您（您的授权服务器）已经知道用户（用户数据库在您自己的系统中处理）时使用。

授权码：消费者（应用程序）使用使用授权码创建的不记名令牌进行调用。授权码由第三方（实际上拥有/管理登录的用户数据）提供，并且创建的授权码链接到登录的用户。 Google 和 Facebook 登录各种网站就是一个典型的例子。 Facebook/Google 为这些网站提供了一个授权代码，然后他们用该代码交换令牌。

隐式授权：密码凭证和授权码的混合。您从第 3 方授权服务器获取不记名令牌，而不是授权码。

问题 1：我认为客户端凭据是正确的方法吗？ 如果您的后端没有用户级逻辑，我认为您可以使用 CC。如果涉及用户级别，可能是 ROPC 是更好的选择

问题 2：客户端 ID 和客户端密码有什么用？ Client ID 和 Client Secret 非常类似于应用程序级别的用户名和密码，用于获取承载令牌。

问题 3：我的后端是否应该隐藏生成客户端 ID 和客户端密码的过程，只提供访问令牌（或）给他们客户端 ID 和客户端密码，然后要求生成访问令牌？ 如果您正在实施 oAuth2，您的消费者应创建访问令牌。但是查看您的用例，甚至可能是 userId+timestamp 的简单哈希就足够了。 ;)

【讨论】：