Pushed Authorization Requests for OIDC

Authorization-request parameters in a front-channel URL are long, leak into logs, and are easy to tamper with in the browser. Pushed Authorization Requests (PAR) let an OIDC client POST those parameters to the authorization server first, then send the user to a short request URI. Authdog OIDC clients can now use PAR, and client secret handling was hardened to match the spec.

This is the longer note behind the August 15 changelog entry.

How it works

The client authenticates to the pushed-authorization endpoint, sends the authorize parameters in the back channel, and receives a request_uri. The user-agent then hits the authorize endpoint with that URI instead of the full query string.

Discovery advertises the pushed authorization request endpoint on the environment issuer. Authdog does not require PAR for every client (require_pushed_authorization_requests stays false). Clients that can PAR should; clients that cannot still use the front channel.

OIDC clients themselves are managed under Authentication > Clients. PAR is a protocol capability of the authorization server, not a separate console module.

Client secret handling on the token and PAR paths was tightened so confidential clients authenticate the way the spec expects (including client_secret_basic and client_secret_post). Public clients that send a secret they should not have are not treated as confidential by accident.

Set it up

1. Create or open an OIDC client under Authentication > Clients in the Authdog console.
2. Use the environment's OIDC discovery document to read pushed_authorization_request_endpoint.
3. From your confidential client, POST the authorization parameters to that endpoint with the client secret, then redirect the user with the returned request_uri.
4. Complete the code exchange at the token endpoint using the same client authentication method.

If you serve identity on a custom domain, read discovery from that host so the advertised PAR URL matches the origin the user will see.

Trust boundaries

PAR moves the parameter set off the query string. It does not replace PKCE, DPoP, or consent. The request_uri is a reference, not a session.

Client secrets stay on the client. Authdog checks them according to the client's registered token-endpoint auth method. Do not put a confidential client secret in a browser or mobile binary and call that PAR.

A successful PAR response is not an access grant. The user still authenticates and the token endpoint still issues tokens.

Try it

Point a confidential OIDC client at discovery, push an authorization request, and complete a sign-in. Client management is Authentication > Clients. Token and session concepts are in Sessions and tokens. The original release note is in the changelog.