Skip to content

OAuth2FlowKind

reference
1 min readUpdated

Kind: Type

Source: atloria-monorepo/packages/ui-core/src/components/api-explorer/oauth2.ts

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'

Was this page helpful?

Download as PDF