OAuth 2.0有多种工作流程。我对其中的两个流程有几个问题。
这两种方法在安全性方面有什么区别？哪一种更安全，为什么？
我不明白为什么一个工作流程中要添加一个额外的步骤（交换授权码以获得令牌），而服务器可以直接颁发访问令牌的原因。
不同的网站说当客户端应用程序可以保护好凭据时，应该使用授权码流。为什么？
access_token是访问受保护资源（API）所需的标记。在授权码流程中，需要完成以下两个步骤以获取access_token：
code。code来交换access_token，并通过client_id和client_secret进行身份验证。access_token调用API。code）的访问权限，应用程序获取access_token，并代表用户发出调用。access_token，您可以使用它来访问资源。 API不知道谁在调用该API。任何人都可以使用access_token，而在上一个例子中，只有Web应用程序可以使用它（通常不对任何人公开其内部）。client id和client secret的情况（例如设备，尽管许多人仍然这样做）。这就是免责声明的意思。人们可以访问客户端代码，因此可以获得凭据并假扮资源客户端。在隐式流程中，所有数据都是易失性的，并且程序中没有存储任何内容。/authorize请求。浏览器和网站试图调用API（也称为客户端）。这是在成功验证后由AS返回的redirect_uri + code。最后，客户端在幕后调用AS，交换code以获取access_token。这是文献中的token endpoint。一般来说，AS从不打电话给任何人。它总是回复。 - Eugenio Paceclient_id和client_secret一起交换authorization code以获取access_token，还是标准提供了在服务器上缓存access_token的方法？ access_token是否会作为头或cookie发送到浏览器？ - samshers我在这里补充一些上面的答案没有明确说明的内容：
简而言之，如果您不信任用户的机器持有令牌但您信任自己的服务器，请勿使用隐式流。
access_token，并借助授权码。 - chirag soni哪个更安全，为什么？
它们两个都是安全的，这取决于你使用它的环境。
我不明白为什么一个额外的步骤（交换授权码以获取令牌）在一个工作流程中添加了，当服务器可以直接发行访问令牌时。
很简单。你的客户端不安全。我们来详细看一下。
假设你正在开发针对 Instagram API 的应用程序，因此你向 Instagram 注册你的应用，并定义你需要哪些 API。 Instagram 将向你提供 client_id 和 client_secret
在你的网站上，你设置了这样一个链接：“来使用我的应用”。点击这个链接，你的 Web 应用程序应该向 Instagram API 发送两个请求。
首先发送一个请求到 Instagram 认证服务器，请求参数如下。
1. `response_type` with the value `code`
2. `client_id` you have get from `Instagram`
3. `redirect_uri` this is a url on your server which do the second call
4. `scope` a space delimited list of scopes
5. `state` with a CSRF token.
您没有发送client_secret，因为您可能不信任客户端（试图使用您的应用程序的用户和/或其浏览器）。 客户端可以查看url或JavaScript并轻松找到您的client_secrect。 这就是为什么您需要另一步的原因。
您将收到code和state。这里的code是temporary的，并且没有被保存在任何地方。
然后，您需要从服务器发起second调用Instagram API。
1. `grant_type` with the value of `authorization_code`
2. `client_id` with the client identifier
3. `client_secret` with the client secret
4. `redirect_uri` with the same redirect URI the user was redirect back to
5. `code` which we have already received.
由于通话是通过我们的服务器进行的，因此我们可以安全地使用 client_secret（显示我们的身份）和 code（显示用户已授予client_id以使用资源）。
作为响应，我们将获得 access_token。
隐式流程中，令牌通过带有"#"符号的重定向URL直接返回，并且这种方式主要用于没有自己服务器端的 JavaScript 客户端或移动应用程序，在某些实现中客户端不需要提供其密钥。
授权码流程中，返回的是带有"?"的代码，服务器端必须提供客户端密钥到令牌URL以从授权服务器获取令牌作为JSON对象，这种方式适用于您拥有能够处理并存储用户令牌及其个人资料的应用服务器，并且通常用于普通移动应用程序。
让我总结一下从以上答案中学到的要点，并加入一些自己的理解。
到目前为止，似乎有两个关键点没有讨论，这解释了为什么授权码授权类型中的绕路会增加安全性。
简短故事：授权码授权类型可以防止浏览器历史记录中出现敏感信息，并且令牌的传输仅依赖于授权服务器的 HTTPS 保护。
更详细的版本：
以下内容将遵循 RFC 中定义的 OAuth 2 术语（它是一个快速阅读）：资源服务器、客户端、授权服务器、资源所有者。
假设您希望某个第三方应用程序（即客户端）访问您的 Google 帐户（即资源服务器）的某些数据。让我们假设 Google 使用 OAuth 2。您是 Google 帐户的资源所有者，但现在您正在操作第三方应用程序。
首先，客户端打开浏览器，将您发送到 Google 授权服务器的安全 URL。然后，您批准访问请求，授权服务器将带着授权码返回给您，回到之前提供的客户端重定向 URL。现在是两个关键点：
使用授权码授权类型，令牌最终由客户端调用授权服务器来获取，传输安全仅取决于授权服务器，而不是客户端。