我正在构建一个非常典型的网络应用产品。它将来可能会有相应的移动应用程序。我正在使用REST API从头开始构建它，使用OAuth2保护它。我有OAuth2工作，我能够使用各种授权类型成功连接。
我有点困惑的是用于实际Web应用程序的授权类型。这就是我的想法：
在用户登录Web应用程序之前，需要对用户注册和密码重置等内容进行一些API访问。我在考虑使用client_credientials授权类型。一个简单的客户端ID和秘密验证，以换取访问令牌。
但是，似乎完全没有必要为每个公共请求甚至每个会话请求访问令牌。仅仅生成我的网络应用程序将始终使用的一个访问令牌似乎更有意义。
然而，这似乎违背了OAuth的设计方式。例如，访问令牌到期。这样做的正确方法是什么？
接下来，对于用户登录Web应用程序，我计划使用password授权类型（资源所有者密码凭据）。这种方法允许我使用访问令牌保存user_id - 因此我知道哪个用户已登录。此外，通过使用范围，我可以限制API中的访问。
我打算在PHP会话中保存访问令牌。只要PHP会话处于活动状态，它们就会保持登录到Web应用程序。
这是用户登录的合适设计吗？
答案 0 :(得分：4)
对于公共API访问：
一种方法是一起跳过令牌，只使用基本HTTP身份验证进行API访问。您可以为此接受客户端凭据，并使用特定于客户端的范围限制客户端可以执行的操作。 Github使用用户凭据提供HTTP Basic authentication所有API调用。
对于私人用户API访问：
这是一个有趣的问题，因为它开始在Authentication和Authorization之间徘徊。 OAuth用于Authorization，因此登录用户变得很糟糕。例如，会话管理是OAuth2.0规范未涵盖的内容。
然而，无论如何，这是OAuth2.0的常见用法。您可以使用password授权类型或任何其他授权类型来获取访问令牌。一个主要的缺点是他们必须用你的密码来信任你的应用程序（对你自己的应用程序来说不是什么大不了的事，但对于第三方来说不是那么多）。此外，在一个地方登录并不一定意味着在其他地方登录（而不是SSO，您有“链接帐户”，因此会话是单独管理的）。解决此问题的一种方法是始终将用户发送到oauth授权端点，如果他们的会话在OAuth2.0提供者端处于活动状态，则使用访问令牌或授权代码将其重新路由回客户端应用程序。这样，如果会话对OAuth2.0提供程序处于活动状态，则客户端可以立即将其登录。