Sign in
auth

Authorize

Start an OAuth sign-in: where to send the browser, and the state to keep.

A GET that writes, which is the one thing to know about it. It records the authorization it is about to start (the state's hash, the PKCE verifier the exchange will need, and the digest of a flow secret it sets as an HttpOnly cookie) so the callback has something to check against, and that record is the whole reason the callback can refuse a code this deployment never asked for, or one presented from a browser other than the one that asked.

Still safe to repeat: each call mints its own state, and only the one the browser kept is the one it sends back. The rows the others leave expire on their own and are swept by the next call. The cookie is reused when the browser already holds one, so a second tab does not break the first.

get/v1/auth/oauth/{provider}/authorize

Path parameters

providerstring required

Which OAuth provider to sign in with.

Which OAuth provider to sign in with.

Response

Successful Response

authorization_urlstring required

The provider consent screen to navigate to.

statestring required

An opaque CSRF value to keep for the length of the redirect, compare against the 'state' the provider returns, and send back with the authorization code. A callback whose state does not match the one held by the browser that started the flow should be abandoned by the client rather than sent here; one that does is checked again against this deployment's own record of it. The response also sets an HttpOnly cookie that the callback requires, so the exchange can only be completed from the browser this call was made from.

Changes