OAuth 2.0 is a token factory, not a login screen
OAuth 2.0 answers one question: how does a client obtain an access token it can present to an API, without handing the API a password on every call? The login page you associate with “Sign in with Google” is one way to get that token. It is not the definition.
The framework has four roles:
- Resource owner – the user (or, in machine flows, nobody).
- Client – the application requesting access.
- Authorization server – issues tokens (the token endpoint, and often an authorize endpoint).
- Resource server – the API that accepts the access token.
The access token is usually a bearer token. After the grant finishes, the API request looks ordinary:
GET /v1/files HTTP/1.1
Host: api.provider.example
Authorization: Bearer eyJhbGciOi...Everything interesting happens before that request: which grant you ran, what you sent to the token endpoint, and how you refresh.
Grants are scenarios, not quality tiers
A grant type is a recipe for swapping one proof for a token. Pick the recipe that matches who is present and whether the client can hold a secret.
+------------------+
user in a browser | authorization |
| code (+ PKCE) |
+------------------+
no user, backend | client |
| credentials |
+------------------+
user + password | resource owner | (legacy)
| password |
+------------------+
SPA, no secret | implicit | (do not use)
+--------+---------+Authorization code
The user authenticates at the authorization server, which redirects back with a short-lived authorization code. The client swaps that code, plus its client_secret, at the token endpoint for tokens. The user’s password never touches the client.
This is the right grant when a human is delegating access (a user connecting Xero, HubSpot, Google). In RequestRocket it is grantType: "authorization_code" on a target oauth2 credential. Required secret fields: appClientId, clientSecret, authURL, accessTokenURL, redirectUri, addToHeader. The credential is created as temporary until the redirect completes; responseMode may be query, fragment, or form_post.
PKCE (Proof Key for Code Exchange)
RFC 7636 extends authorization code for public clients that cannot hide a client secret (mobile apps, many SPAs). The client generates a random code_verifier, sends its hash (code_challenge, usually S256) when starting the flow, and reveals the verifier when redeeming the code. An attacker who intercepts the code still cannot redeem it.
RequestRocket models this as its own grant, grantType: "pkce", not as a flag on authorization code. clientSecret is optional. Required: appClientId, authURL, accessTokenURL, redirectUri, addToHeader. codeChallengeMethod is S256 or plain – use S256.
Client credentials
No user. The client authenticates as itself with client_id and client_secret at the token endpoint and receives an access token. This is the workhorse for backend-to-backend and agent-to-SaaS calls.
Required secret fields: appClientId, grantType: "client_credentials", clientSecret, accessTokenURL, addToHeader. There is no authURL and no redirect. clientAuthInHeader controls whether those client credentials go in an Authorization: Basic header or in the token-request body – vendors disagree, and getting this wrong is the most common 401 when standing up a new integration.
Resource owner password
The client collects a username and password and posts them to the token endpoint. OAuth 2.1 discourages it because the client sees the password. It survives in first-party and legacy systems that never grew an authorize endpoint.
Required: appClientId, grantType: "password", clientSecret, accessTokenURL, username, password, addToHeader. Treat it as a compatibility grant, not a design target.
Implicit – deprecated, not implemented
Implicit returned tokens in the URL fragment so a browser app without a backend could skip the code exchange. Tokens leaked via browser history, Referer headers, and logs. OAuth 2.1 removes it. Public clients should use authorization code with PKCE.
RequestRocket has no implicit grant type. The oauth2 enum is authorization_code | password | client_credentials | pkce. If a vendor still documents implicit, use PKCE instead or ask them for a confidential-client flow.
Refresh is part of the grant, not a fifth grant
Authorization-code and PKCE flows typically return a refresh token. When the access token’s tokenExpiresIn window closes, the client posts the refresh token (to refreshURL if the vendor uses a separate endpoint, otherwise the token endpoint) and gets a new access token without repeating the user login.
Client-credentials and password grants can usually just re-run: there is no user to re-prompt. A gateway that stores accessToken, refreshToken, tokenReceivedAt, and tokenExpiresIn on the credential is doing this so application code does not.
OAuth refresh is not token exchange (RFC 8693). Refresh keeps the same grant alive. Token exchange mints a different token, often for a different audience.
What a gateway actually stores
oauth2 is a target credential in RequestRocket – outbound only. Proxy credentials do not run OAuth grants; inbound user login is not the product. The access token is attached with addToHeader (header versus query) and an optional prefix (usually Bearer).
MCP-specific claim checks after a token is already valid stay in Controlling what MCP callers can access using JWT claims. The survey of every upstream scheme stays in API authentication methods explained.
Next steps
If the upstream is OAuth, create a target credential with the matching grantType and let the gateway refresh. Field-level detail is in the credentials guide. RequestRocket is runtime access control for AI agents and apps calling APIs you don’t own – every call gets a least-privilege credential, a policy check, and an audit record, with no code changes.