What properties does an authorization code have, and why?

It is a random string generated by the authorization server, valid only briefly (typically about 10 minutes), usable only once, and bound to the client ID and redirect URI it was issued for.

Each property removes one way of abusing a stolen code:

• Short lifetime (about 10 minutes, the maximum RFC 6749 recommends): the code only has to survive the few seconds between the redirect and the token request. A code found later in a log file has already expired.
• Single use: once redeemed, it cannot be redeemed again. If the authorization server sees a second attempt, it must deny it and should, where possible, revoke the tokens already issued for that code, because a second redemption signals that the code was stolen.
• Bound to client ID and redirect URI: at the token endpoint the server checks that the client redeeming the code is the one it was issued to, and that the redirect URI matches the one in the original request. A code stolen from one client cannot be redeemed by another.

These properties are why the code can travel through the comparatively unsafe browser while the tokens it unlocks stay protected.

Go deeper:

• RFC 6749, Section 4.1.2: Authorization Response — the lifetime, single-use and binding rules for authorization codes.