## 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

```text
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/pst_k59PDLvmwGVwLyN1s_R-xg