Skip to main content

Start an authorization (redirects to the consent screen)

GET 
/oauth/authorize

Where an app sends an admin to install it. Answers 302 to the consent screen on the app host — https://app.kudoscrm.com/oauth/authorize?<the same query> — and checks nothing itself: the consent screen reads the request through the consent API once it knows who is signed in, and shows every problem there. The discovery document names the consent screen itself as authorization_endpoint; both work.

The request is RFC 6749 §4.1.1 with PKCE (RFC 7636): response_type=code, your client_id (app_<key>), a redirect_uri registered on your app's live version (exactly, character for character), the catalog scopes you want (space-separated; leave it out for every scope your version requests), an opaque state (≤500 characters, echoed back), and code_challenge with code_challenge_method=S256. PKCE is required for every app (plain is refused).

On Allow the browser comes back to redirect_uri with code (a kac_… code, valid 10 minutes, single use), your state and iss (the issuer, RFC 9207); on Deny with error=access_denied. An error the consent screen can send back only goes to a registered URI of a public app's live version.

Throttle: oauth/authorize/ip, 120 a minute per IP.

Request​

Responses​

To the consent screen on the app host, with the query untouched.

Response Headers
    Location
    Example: https://app.kudoscrm.com/oauth/authorize?response_type=code&client_id=app_acme_dialer&redirect_uri=https%3A%2F%2Fapp.example.com%2Fintegrations%2Fkudos%2Fcallback&state=xyz&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&code_challenge_method=S256
    Cache-Control

    Every OAuth answer — a token response cached by a proxy is a leaked token (RFC 6749 §5.1).