Discover the PAR endpoint from the authorization server metadata document (/.well-known/oauth-authorization-server or /.well-known/openid-configuration) by reading the pushed_authorization_request_endpoint field
POST the full authorization request parameters (client_id, response_type, scope, redirect_uri, code_challenge, state, etc.) to the pushed_authorization_request_endpoint using client authentication (client_secret_basic or private_key_jwt)
Receive a JSON response containing request_uri (a urn:ietf:params:oauth:request_uri:... value) and expires_in seconds
Redirect the user-agent to the authorization endpoint with only client_id and request_uri as query parameters — omit all other parameters
Complete the standard authorization code flow: receive the code at your redirect_uri, then POST to the token endpoint to exchange it for tokens
Check the server metadata field require_pushed_authorization_requests (boolean) — if true, the server rejects direct authorization requests not submitted via PAR
Known gotchas
The authorization server metadata field is exactly pushed_authorization_request_endpoint (RFC 9126 Section 5) — not par_endpoint, pushed_auth_request_endpoint, or any other variant
The request_uri returned from the PAR endpoint is single-use and short-lived (expires_in seconds); it must be used in the authorization redirect promptly and cannot be reused
When using PAR with PKCE, the code_challenge and code_challenge_method must be included in the PAR POST body, not in the subsequent authorization redirect
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp