资源和身份验证服务器相同时如何实现OAuth

Question

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

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

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

问题1：客户凭证是正确的方法，对吗？

对于那些企业用户来说，仅通过UI界面获得访问令牌就足够了，以便他们可以访问我们的所有API。 但是，这里的问题是又一个步骤，即首先获取客户端ID和客户端密钥，然后使用它来获取访问令牌。

问题2：客户端ID和客户端机密有什么用？

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

问题4：如果我给他们提供没有客户端ID和密码的访问令牌，那么拥有无限的到期时间就可以了吗？和

TLDR； 资源服务器和身份验证服务器相同时如何实现OAuth？

Answer 1

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

我认为，如果您在进行任何实现之前先通过this，那会更好。它提供了在实施OAuth系统之前应具备的大多数基本知识。我希望这个答案对您有用。

Answer 2

  

问题1：客户凭证是正确的方法，对吗？

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

  

问题2：客户端ID和客户端机密有什么用？

• 客户端ID允许身份验证服务器识别应用程序 请求令牌（通常会传递给访问令牌 也允许API识别调用应用程序。
• 客户端密钥表示身份验证服务器可以信任客户端 他说的是他的真实身份，因为只有他应该有私人客户 公开客户ID的秘密。

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

  

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

您的Auth服务器应向应用程序一次颁发客户端凭据，并且每次他们希望通过客户端凭据授予类型获取令牌时，应用程序都应提供这些凭据。

Answer 3

oAuth2中有4种授予类型，分别用于不同的情况。

client凭据：消费者（应用程序）仅使用通过apikey（或clientId）和机密创建的承载令牌来调用后端。通常用于检索通用信息的匿名呼叫。

资源所有者密码凭证（ROPC）：消费者（应用程序）使用使用apikey，secret，用户名和密码创建的承载令牌进行呼叫。通常在您（您的授权服务器）已经知道用户（用户数据库在您自己的系统中处理）时使用。

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

隐式授予：密码凭证和授权码的混合。您可以从第三方授权服务器获取承载令牌，而不是授权代码。

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

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

问题3：我的后端是否应该隐藏生成客户端ID和客户端密钥的过程，而只提供访问令牌（或者）给它们提供客户端ID和客户端密钥，然后要求生成访问令牌？   如果要实现oAuth2，则使用者应创建访问令牌。但是查看您的用例，甚至仅使用userId + timestamp的简单哈希即可。 ;）