Authorization endpoint (consent screen)

RFC 6749 §4.1.1 authorization endpoint: this is what an OAuth client
redirects the user's browser to. Not a JSON API: it renders an HTML
page.

If client_id or redirect_uri can't be verified against a
registered client, it renders an inline error page directly (there
is nowhere safe to redirect to).

Otherwise, if the visitor isn't signed in to upload.tf, it sends them
to sign in first, then back here.

Once signed in, it renders a consent screen naming the client and
the scopes it's requesting. The visitor's Allow/Deny decision is
submitted via a same-origin form POST (not a public API, see
POST /api/oauth/authorize below), which redirects the browser back
to redirect_uri with either ?code=…&state=… (RFC 6749 §4.1.2) or
?error=…&error_description=…&state=… (§4.1.2.1).

If the signed-in account has not confirmed its email address, the
consent screen explains that instead of offering Allow/Deny. No
authorization code is issued until the address is confirmed.

PKCE (code_challenge + code_challenge_method=S256) is mandatory:
plain is rejected outright, and a request missing PKCE fields
never reaches a consent screen.

API Key

Add parameter in header

x-api-key

Example:

x-api-key: ********************

Bearer Token

Provide your bearer token in the

Authorization

header when making requests to protected resources.

Example:

Authorization: Bearer ********************

curl --location 'https://upload.tf/api/v1/oauth/authorize?client_id=undefined&redirect_uri=undefined&response_type=undefined&scope=undefined&code_challenge=undefined&code_challenge_method=undefined&state=undefined&resource=undefined' \ --header 'x-api-key: <api-key>'

Request

Responses