OAuth typically starts with the client asking for specific scopes (permissions), like read:calendar.
A common modern pattern is the Authorization Code flow:
Because the redirect passes through the user’s browser, URL history, logs, and intermediaries. The code is meant to be a short-lived “placeholder” that’s safer to handle in the front channel, while the token exchange happens in a more controlled back channel.
Redirects aren’t an awkward workaround—they’re how the user authenticates and consents directly with the authorization server, not with the client.
Why does the Authorization Code flow use a short-lived authorization code before issuing an access token?
The key idea is reducing exposure: the browser redirect is a leaky place to deliver long-lived secrets, so OAuth uses a code in the front channel and swaps it for tokens in a back-channel request. It’s common to assume the code is about delaying consent, but consent happens before the code is issued. Browser-dependent token generation and manual copy/paste are both misconceptions that confuse OAuth with ad-hoc API key sharing.
Which token is primarily meant to be presented to the API (resource server) to access protected endpoints?
The access token is what the resource server expects on API calls (often in an Authorization header). Refresh tokens are for the client to obtain new access tokens and typically should not be sent to APIs. Authorization codes are temporary artifacts used only during the exchange step. ID tokens are about user identity in OpenID Connect and are a common source of mix-ups because they look like tokens but have a different job.