# OAuth2FlowKind

**Kind:** Type

**Source:** [`atloria-monorepo/packages/ui-core/src/components/api-explorer/oauth2.ts`](https://github.com/sherkety/atloria/blob/main/atloria-monorepo/packages/ui-core/src/components/api-explorer/oauth2.ts#L26)

OAuth2 for the playground.

The explorer understood exactly one credential: a bearer token the reader pastes. Most APIs
worth documenting sit behind an OAuth2 flow, so a reader arriving with an account and no
hand-minted token had nothing to try the API with.

Everything here is a pure function over a spec, a URL, or a token response, with the browser's
crypto and storage passed IN — so the flow logic is testable without a redirect, and the
component keeps no OAuth2 knowledge of its own.

What this deliberately does NOT do, and why:
 - No client secret, ever. A documentation page is a PUBLIC client: anything it holds is
   readable by anyone who opens it. That rules out `clientCredentials` and makes PKCE
   mandatory rather than optional.
 - No `password` flow. It requires putting a password field in front of a reader who never
   signed in to this page — the same reason `allowCredentialLogin` is off by default.
 - No refresh token is ever persisted. A refresh token is a long-lived credential; the
   access token expires and the reader re-authorizes, which costs one click.
 - The token exchange is never proxied through Atloria. Routing it server-side would put the
   authorization code and the verifier — and therefore the reader's token — through our
   infrastructure, for an API that is not ours. A public client's token endpoint is required
   to allow CORS (RFC 8252 / OAuth 2.0 for Browser-Based Apps); when it does not, we say so.

## Definition

```ts
'authorizationCode' | 'implicit' | 'clientCredentials' | 'password'
```