oAuth2.0：为什么需要“授权代码”，并且只需要令牌？

Question

使用oAuth 2.0，在“授权代码”授权授予中，我首先调用“/授权”，获取代码，然后在对“/令牌”的调用中使用该代码来获取访问令牌。

我的问题：为什么这是流？我想这是出于安全原因，但我想不出来。为什么实现是这样的，而不是在第一次调用（“/authorize”）后立即获取访问令牌？

为什么我们需要这个代码？

Answer 1

客户端的数据通常被认为是不安全的。在隐式调用的情况下，令牌在初始步骤中被授予，任何有access_token的人都可以请求数据，应用编程接口不知道谁在调用该应用编程接口。

但是，在应用程序想要标识自己的Web服务器应用程序的情况下，client_secretclient_id与authorization_code一起发送以获得access_token，将来可以独立发送。

假设，如果access_token最初被授予，那么client_id和access_token仍然会被认为是公开的，所以应用程序将不得不发送client_secret除了access_token每次以确保请求真的来自它。

而在当前场景中，在获得访问\u令牌后，可以独立地发出进一步的请求，而不需要客户端\u密钥。

Answer 2

授权代码流适用于涉及3方的场景。

这些缔约方是：

>

客户

用户使用其web浏览器。他想使用你的应用程序。

供应商

包含有关用户的信息。如果有人想访问这些数据，用户必须首先同意。

您的（web）应用程序

希望从提供者访问关于用户的信息。

现在，你的应用程序对用户说（将他的浏览器重定向到/authorizeendpoint）：

嘿，用户，这是我的客户id。请与提供商联系，并允许他直接与我联系。

因此，用户与提供商交谈（请求授权码并通过在其浏览器中打开您的回调URL将其返回到您的应用程序）：

嘿，提供商，我想使用这个应用程序，所以他们需要访问我的数据。给我一些代码，我给应用程序这个代码。

现在，您的应用程序具有客户端和提供商已知的授权代码。通过将其交给提供商，您的应用程序现在可以证明，客户端允许其访问其数据。提供商现在向您的（web）应用程序颁发访问令牌，这样您的（web）应用程序就不必每次都重复这些步骤（至少在一段时间内）。

如果其他应用程序类型的应用程序直接在客户端运行（如iPhone/Android应用程序或Javascript客户端），则中间步骤是多余的。

Answer 3

也有可能通过这个中间步骤阻止客户端看到访问令牌吗？

摘自O'Reilly的书：

授权代码此授权类型最适合服务器端web应用程序。在资源所有者获得对其数据的授权访问后，他们将被重定向回web应用程序，并在URL中使用授权代码作为查询参数。客户端应用程序必须将此代码交换为访问令牌。此交换是服务器对服务器进行的，需要客户端\u id和客户端\u机密，甚至资源所有者也无法获得访问令牌。这种授权类型还允许通过使用刷新令牌对API进行长期访问。

用于基于浏览器的客户端应用程序的隐式授予隐式授予是所有流中最简单的，并且针对在浏览器中运行的客户端Web应用程序进行了优化。资源所有者授予对应用程序的访问权限，并立即创建一个新的访问令牌，并使用URL中的#哈希片段传回应用程序。应用程序可以立即从哈希片段中提取访问令牌（使用JavaScript）并发出API请求。此授予类型不需要中介“授权代码”，但它也不提供可用于长期访问的刷新令牌。

更新-确实是：

什么时候应该使用授权代码流？授权代码流应在以下情况下使用

>

需要长期访问。

OAuth客户端是一个web应用程序服务器。

API调用的责任是非常重要的，OAuth令牌不应该泄露给浏览器，用户可以在浏览器中访问它。

更多：

也许最重要的是，因为访问令牌从未通过浏览器发送-通过浏览器历史记录、引用器头、JavaScript等将访问令牌泄漏给恶意代码的风险较小。