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
clientCredentialsand makes PKCE mandatory rather than optional. - No
passwordflow. It requires putting a password field in front of a reader who never signed in to this page — the same reasonallowCredentialLoginis 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?