oAuth2.0: Why need "authorization-code" and only then the token?

The authorization code flow is meant for scenarios where 3 parties are involved.

These parties are:

• Client

  The user with his web browser. He wants to use your application.

• Provider

  Has information about the user. If somebody wants to access this data, the user has to agree first.

• Your (web) application

  Wants to access information about the user from the provider.

Now your app says to the user (redirecting his browser to the /authorize endpoint):

Hey user, here is my client id. Please talk to the provider and grant him to talk to me directly.

So the user talks to the provider (requests the authorization code and returns it to your app by opening your callback URL in his browser):

Hey provider, I want to use this app, so they require to access my data. Give me some code and I give this code to the application.

Now your app has the authorization code which is already known by client AND the provider. By handing this over to the provider your app can now prove, that it was allowed by the client to access his data. The provider now issues your (web) app an access token, so your (web) app won't have to redo these steps each time (at least for a while).

In case of other application types where your app is running directly at the client side (such as iPhone/Android apps or Javascript clients), the intermediate step is redundant.

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 resource 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 exchange is done server-to-server and requires both the client_id and client_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 immediately 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.

• Accountability for API calls is very important and the OAuth token shouldn’t be leaked to the browser, where the user may have access to it.

More:

Perhaps most importantly—because the access token is never sent through the browser— there is less risk that the access token will be leaked to malicious code through browser history, referer headers, JavaScript, and the like.