OAuth授权代码和隐式工作流之间的区别是什么？什么时候使用每一个？
OAuth2.0有多个工作流。关于这两个问题，我有几个问题。
-
null
这两种方法在安全性方面有什么不同？哪一个更安全，为什么？
当服务器可以直接发出访问令牌时，我看不出为什么在一个工作流中添加额外的步骤（令牌的交换授权代码）。
不同的网站说，授权码流是在客户端应用程序可以保持凭据安全的情况下使用的。为什么？
共有1个答案
access_token是调用受保护资源（API）所需的。在授权代码流中，有两个步骤可以获得它：
- 用户必须进行身份验证，并将
代码返回给API使用者（称为“客户端”）。 - API的“客户端”（通常是您的web服务器）将#1中获得的
代码交换为access_token，并使用client_id和client_secret对自身进行身份验证
- 然后它可以使用
access_token. 调用API
因此，有一个双重检查：拥有通过API浮出水面的资源的用户和使用该API的客户机（例如，web应用程序）。两者都经过验证以获得访问权限。请注意OAuth的“授权”特性：用户（通过身份验证后返回的代码)将对其资源的访问权授予应用程序，该应用程序将获得access_token，并代表用户调用。
在隐式流中，步骤2被省略。因此，在用户身份验证之后，将直接返回access_token，您可以使用它来访问资源。API不知道谁在调用该API。任何具有access_token的人都可以，而在前面的示例中，只有web应用程序可以（它是内部的，通常不是任何人都可以访问的）。
隐式流通常用于不建议存储客户机ID和客户机机密的场景（例如，尽管许多设备都这样做）。这就是免责声明的意思。人们可以访问客户机代码，因此可以获得凭据并假装成为资源客户机。在隐式流中，所有数据都是易失性的，应用程序中没有存储任何数据。
-
我想更好地理解隐式授权流和授权代码授权流之间的区别，因为我不确定我目前的理解是否正确。 隐式授权流主要由前端应用程序用于验证用户身份吗？ 隐式授权流是否只需要一个client_id、用户名和密码来进行身份验证，换句话说，永远不会发送client_secret？ 授权码只是一个短期令牌吗？ 将授权码交换为访问令牌后，客户端可以访问用户帐户多长时间？具体地说，如果客户端是一个长时间运行的脚本，那么用户
-
问题内容： 在我的情况下： 要么 没关系，有什么区别？ 问题答案： 使用自定义类型： 使用了内置的简单类型： 使用复杂的内建类型： 最后一个有点棘手：
-
使用“隐式”流，在资源所有者（即用户）给予访问权限后，客户端（可能是浏览器）将获得访问令牌。 然而，在“授权代码”流程中，客户端（通常是web服务器）只有在资源所有者（即用户）给予访问权限后才获得授权代码。使用该授权代码，客户机然后对API进行另一次调用，将client_id和client_secret与授权代码一起传递，以获得访问令牌。这里都描述得很好。 问题是：当“隐式”流接缝很好时，为什么还
-
null 现在，我仍然困惑的是，登录验证应该从哪里来（登录用户名-密码）？是否在转到OAuth流之前进行单独的验证，一旦用户有效，它就应该回到流中？
-
在另一个关于将字符串作为字符数组进行单步执行的线程中，提示这个问题的具体注释是“注意，此技术给您的是字符，而不是代码点，这意味着您可能获得代理项。”我不是真的理解，所以我想最好是在一个新的问题中要求澄清，而不是对一个5年前的问题进行一系列的评论。
-
问题内容： 所述流文档状态双工流 “是同时实现可读写接口流”和变换流 “是双相流其中输出以某种方式从输入计算”。不幸的是，文档没有描述Transplex流在Duplex流之外提供的内容。 两者之间有什么区别吗？您什么时候可以使用另一个？ 问题答案： 可以将双工流视为具有可写流的可读流。两者都是独立的，每个都有独立的内部缓冲区。读写事件独立发生。 转换流是双工的，其中读写以因果关系进行。双工流的端点