oAuth2.0:为什么需要"授权代码"而只需要令牌？

Question

使用oAuth 2.0,在"授权代码"授权授权中,我首先调用"/ authorize",获取代码,然后在调用"/ token"时使用此代码来获取访问令牌.

我的问题:为什么这是流程？我想这是出于安全原因,但我无法弄明白.为什么实现是这样的,并且在第一次调用("/ authorize")之后没有立即获取访问令牌？

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

Answer 1

该授权码流是为其中的3方参与的情况.

这些政党是:

• 客户

  用户使用他的网络浏览器.他想用你的申请.

• 提供商

  有关于用户的信息.如果有人想要访问此数据,则用户必须先同意.

• 您的(网络)应用程序

  想要从提供者访问有关用户的信息.

现在您的应用向用户说明(将浏览器重定向到/authorize端点):

嘿用户,这是我的客户端ID.请与提供商联系并授予他直接与我交谈的权利.

因此,用户与提供者交谈(请求授权代码并通过在浏览器中打开回调URL将其返回到您的应用程序):

嘿提供者,我想使用这个应用程序,所以他们需要访问我的数据.给我一些代码,我将此代码提供给应用程序.

现在,您的应用程序具有客户端和提供商已知的授权代码.通过将其交给提供商,您的应用程序现在可以证明,客户端允许访问其数据.该供应商的问题,目前您的(网络)的应用的访问令牌,让您的(网络)的应用程序不会有(至少暂时的)每次重做这些步骤.

如果您的应用程序直接在客户端运行的其他应用程序类型(例如iPhone/Android应用程序或Javascript客户端),则中间步骤是多余的.

Answer 2

Could it also be that by having this intermediate step prevents the client from seeing the access token?

From O'Reilly book:

Authorization code This grant type is most appropriate for server-side web applications. After the re- source owner has authorized access to their data, they are redirected back to the web application with an authorization code as a query parameter in the URL. This code must be exchanged for an access token by the client application. This ex- change is done server-to-server and requires both the client_id and cli ent_secret, preventing even the resource owner from obtaining the access token. This grant type also allows for long-lived access to an API by using refresh tokens.

Implicit grant for browser-based client-side applications The implicit grant is the most simplistic of all flows, and is optimized for client- side web applications running in a browser. The resource owner grants access to the application, and a new access token is immediately minted and passed back to the application using a #hash fragment in the URL. The application can immedi- ately extract the access token from the hash fragment (using JavaScript) and make API requests. This grant type does not require the intermediary "authorization code," but it also doesn’t make available refresh tokens for long-lived access.

UPDATE - yes indeed:

When Should the Authorization Code Flow Be Used? The Authorization Code flow should be used when

• Long-lived access is required.

• The OAuth client is a web application server.

• API调用的问责制非常重要,OAuth令牌不应泄露给用户可以访问的浏览器.

更多:

也许最重要的是 - 因为访问令牌永远不会通过浏览器发送 - 访问令牌通过浏览器历史记录,引用标头,JavaScript等泄露给恶意代码的风险较小.

Answer 3

客户端数据通常被认为是不安全的.对于在初始步骤中授予令牌的隐式调用,具有access_token的任何人都可以请求数据,API不知道谁在调用该API.

但是,对于应用程序想要识别自身的Web服务器应用程序,带有client_secret的client_id与authorization_code一起发送以获取access_token,以后可以独立发送.

假设,如果最初自己授予access_token,那么client_id和access_token仍将被视为公开,因此除了access_token之外,app还必须每次发送client_secret以确保请求确实来自它.

在当前场景中,在获得access_token之后,可以独立地进行进一步的请求而无需client_secret.