oauth 隐式授权与授权码授权？

Posted 2023-03-04

【中文标题】oauth 隐式授权与授权码授权？

【英文标题】：oauth implicit grant vs authorization code grant?

【发布时间】：2018-11-21 18:02:56

【问题描述】：

我想更好地理解隐式授权流程和授权代码授权流程之间的区别，因为我不确定我目前的理解是否正确。

隐式授权流程是否主要由前端应用程序用于对用户进行身份验证？ 隐式授权流程是否只需要 client_id、用户名和密码进行身份验证，换句话说，client_secret 永远不会发送？ 授权码是否只是短暂的令牌？ 授权码换取访问令牌后，客户端可以在多长时间内访问用户帐号？具体来说，如果客户端是一个长时间运行的脚本，那么每次脚本运行时用户都需要认证吗？或者我们可以假设在用户授权一次之后，客户端有权在需要时访问用户（除非用户撤销访问权限），因此它只需要使用客户端凭据进行身份验证？ 与隐式流相比，使用授权码流有什么优势？ 它自己的资源服务器是否需要客户端 ID？

谢谢

【参考方案1】：

The OAuth 2.0 Authorization Framework (RFC 6749) 暗示：

隐式流程仅适用于基于浏览器或 javascript 的 OAuth 客户端应用程序不适合移动设备或其他可能使用授权码授予的应用程序

隐式授权类型用于获取访问令牌（它不 支持刷新令牌的发行）并针对公共进行了优化 已知操作特定重定向 URI 的客户端。

有关使用隐式授权的背景信息，请参阅第 1.3.2 节和第 9 节。 有关重要的安全注意事项，请参阅第 10.3 节和第 10.16 节 使用隐式授权时。

当使用隐式授权类型时，访问令牌在 URI 片段中传输，这可能会将其暴露给未授权方。

-吉姆

【讨论】：

是什么阻止了某人扩展您的服务并构建仅使用隐式授权的移动应用程序？

授权服务器可以根据客户端注册和它可用的任何其他参数决定不接受隐式授权。类似于用户代理类型。

【参考方案2】：

虽然 jwilleke 回答了您的大部分问题，但我会回答您的具体问题，

隐式流程专为无法执行令牌请求的客户端设计。来自 OAuth 2.0 规范 - 4.2 section

隐式授权类型用于获取访问令牌（它不 支持刷新令牌的发行）并针对公共进行了优化 已知操作特定重定向 URI 的客户端。这些客户 通常使用脚本语言在浏览器中实现 比如 JavaScript。

它被公共客户使用。他们没有客户机密。这是因为它们运行在浏览器上，无法保护这些秘密。

授权码的有效期可以是几秒（30 秒）到几分钟（2 分钟）。与其他代币相比，它们的寿命很短。

这取决于访问令牌的生命周期。如果有长时间运行的任务并且令牌过期，您将必须获取新的访问令牌以进行授权。但是，如果您的特定后端建立会话，它的生命周期可能会比访问令牌更长。

一个优点是刷新令牌。它可用于在没有最终用户交互（新登录）的情况下刷新访问令牌。此外，根据 OAuth 服务器的实现，您可能会获得具有不同生命周期的访问令牌。例如，授权服务器可能会为隐式流颁发短期访问令牌，因为它被公共客户端使用。

这取决于。如果资源服务器需要使用来自另一个资源服务器的受保护资源，该资源服务器授权使用访问令牌，那么您的资源服务器也将需要一个客户端 ID 并遵循特定流程来获取令牌。但如果它不与外部通信，则不必为其获取客户端 ID。

【讨论】：

当您说“建立会话”时，您的意思是后端应用已交换 client_credentials 以进行身份​​验证，而不是通过身份验证代码？

如果是这样，一旦用户同意客户端使用特定资源。客户端是否可以在将来使用说 client_credentials 进行身份验证，并且仍然可以访问同意的资源。

@Freid001 不是客户端凭据。后端可以验证访问令牌，如果有效，则在客户端之间建立会话。

@Freid001 不要混淆客户端凭据和资源所有者授权。在 OAuth 上下文中，它们是两个不同的东西（一开始就令人困惑）。客户端是您使用受保护资源的应用程序。最终用户是典型的人类用户（或类似用户）。客户端凭据不会暴露给受保护的资源，但 Oauth 2 中有一些流程允许您与 authN 服务器交换它们以获取令牌

所以客户端凭据流允许应用程序在没有用户上下文的情况下获取令牌？