docs said OAuth2 without specifying the flow - the agent picked implicit grant and the provider disabled it years ago

TL;DR

Probe the provider's authorization endpoint first: if implicit grant is disabled you get a deprecation error in seconds, not after a day of debugging. Pick a flow the provider actually supports (auth-code for user apps, client-credentials for headless agents), then regenerate the auth module for that flow. When the docs never name the flow, "unspecified" means unknown, never implicit.

The query

docs said OAuth2 without specifying the flow  -  the agent picked implicit grant and the provider disabled it years ago

Steps

1. Confirm implicit is actually dead

Hit the authorization endpoint the way the generated code does and read the response body. A disabled implicit grant returns something like unsupported_response_type or a deprecation notice. Do not guess from old blog posts.

Expected: the provider's real answer about the implicit grant - an error naming the disabled grant type, or a working redirect.

2. Find which flows are alive

Check the provider's OAuth docs changelog or authorization server metadata for the supported response types and grant types. Look for a security notice: most providers published one when they killed implicit. Note the date and the replacement flow.

Expected: a short list of supported flows, e.g. authorization code with PKCE plus client credentials.

3. Pick the flow for the client type

A headless agent with no browser and no user is not an implicit-grant client even when implicit works. Pick auth-code with PKCE when a user is present, client-credentials when the integration runs server-side unattended. The generated client must match the runtime it will live in.

Expected: one flow chosen from the supported list, justified by the client type.

4. Regenerate the auth module for the chosen flow

Throw away the implicit-grant redirect code and generate the real flow: token request to the token endpoint, code exchange or client assertion as the flow requires, refresh handling. Leave a comment at the top of the file naming the flow and why implicit was rejected.

Expected: an auth module with no implicit-grant code paths and a comment recording the decision.

5. Smoke-test a token request end to end

Run one real token request with the regenerated code and confirm a 200 with an access token. Do not generate the rest of the client until auth returns a token.

Expected: a 200 response containing an access token, proving the flow works against the live provider.

Use this when

• Generated code uses response_type=token or fragment-based token delivery
• The provider disabled implicit years ago (check its security changelog)
• Docs say "OAuth2" with no named flow and the agent defaulted to implicit
• The authorization endpoint returns unsupported_response_type

Not for this skill when

• The flow works but tokens expire without refresh (refresh wiring problem)
• Client ID or secret is wrong (credential problem)
• A scope error on a flow that otherwise completes
• The provider supports implicit but the code has a redirect-URI bug (different fix)

Variant phrasings

agent implemented OAuth PKCE for a machine-to-machine integration

Same decision process in reverse: PKCE implies a user is present. For a headless server-side agent, step 3 lands on client-credentials instead.

docs said OAuth2 without specifying the flow, agent picked auth-code

Run the same steps. If the provider supports auth-code and a user is present, the agent guessed right; verify with step 1 rather than rewriting on suspicion.

Why it happens

Implicit grant was the default "just put a token in the URL" answer in old docs and old training data, so a doc-reading agent reaches for it when the docs never name a flow. Providers deprecated it years ago because tokens in URL fragments leak through browser history and logs, and the deprecation notice lives in a security changelog the agent never opened. The agent generated code that faithfully implements a flow the provider no longer accepts.

Edge cases

• Provider supports implicit for legacy apps only: new client registrations may be blocked even when old ones work. Register a fresh client and test with it.
• Docs show implicit in examples but the text says deprecated: trust the deprecation notice, not the example. Examples rot faster than policy pages.
• The integration genuinely runs in a browser with a user: then auth-code with PKCE is the answer, not implicit. Same steps, different flow in step 3.
• Hybrid docs that mix flows across sections: pin the flow decision to the client type (step 3) and stop reading docs as a single coherent spec.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstk59PDLvmwGVwLyN1sR-xg