【发布时间】：2018-09-17 16:44:31
【问题描述】：
隐式授权是经过优化的简化授权代码流程 对于使用脚本语言在浏览器中实现的客户端，例如 作为 JavaScript。
资源所有者密码凭据（即用户名和密码） 可以直接用作授权授予来获得访问权限 令牌。
(https://www.rfc-editor.org/rfc/rfc6749#section-1.2)
我的问题是关于了解这两种资助类型有何不同？
【问题讨论】：
标签： oauth-2.0
【发布时间】：2018-09-17 16:44:31
【问题描述】：
重要的是要了解输入凭据的方式和位置。
隐式
您的应用程序是https://example.com，对于身份验证，您将使用https://auth.some-domain.com（甚至https://auth.example.com）。认证成功后，用户被重定向到https://example.com/some-callbackurl?#token=token-value。
注意点：URL中的重定向和token
资源所有者密码流程
您的应用是https://example.com，对于身份验证，您将转到https://example.com（或https://example.com/login）。认证成功后，用户被重定向到https://example.com/home。
注意点：URL中没有重定向和令牌交换
基本上，如果您拥有应用程序（客户端应用程序、服务器应用程序、身份验证应用程序），那么您会这样做。基本上，您是负责身份验证的人 - 而不是第三方应用程序。您信任您的客户端应用程序。
https://example.com/login 从用户获取凭据并执行 HTTP REST POST（例如）调用并以令牌的形式获取响应（并刷新令牌 - 可选）。它将它保存在localStorage 或cookie 中，然后重定向到主页或它必须重定向到的任何页面。
交换时不会发生重定向。
【讨论】：
-
在使用密码授权类型时，客户端 ID 和客户端密码会发生什么情况？配置时不是必须的吗？
-
Client Id在任何授权类型中都是必需的。客户端密码在password流中可以是可选的，因为用户 - 资源所有者无论如何都会输入用户名和密码，因此可以将其视为有效的凭据/密码
正如您所引用的，“资源所有者密码凭据授予”适用于资源所有者与客户端具有信任关系的情况，例如设备操作系统。一个例子是 Facebook 应用程序 - Facebook 信任他们安装在设备上的应用程序。
因此，客户端应用程序不必在身份验证服务器中注册。正如您在request 中看到的，client_id 没有作为参数传输。此外，流程更简单 - 在单个请求中检索访问令牌。
【讨论】：