Pushed Authorization Requests

What is it?

The OAuth 2.0 Pushed Authorization Requests specification improves security of the Authorization Code Flow so that the end user cannot tamper or modify the parameters used to start the flow.

Additional Parameters

The Pushed Authorization Request uses all the parameters of the Authorization Code Flow and adds one additional parameter.

• Request URI: A value obtained from a POST to the REQUEST_ENDPOINT endpoint used to lookup the authorization parameters.

How do I use it?

A Pushed Authorization Request adds an additional step to the Authorization Code Flow so that the typical parameters sent to the Authorization Request are not exposed to the User.

See the Authorization Code Flow for key concepts and parameter definitions.

Step-by-Step Authorization Code Flow

1. Pushed Authorization Request

Submit OAuth parameters in a POST request to the request endpoint:

• client_id (application identifier)
• redirect_uri (pre-registered callback URL)
• response_type=code (specifies the Authorization Code flow)
• scope (permissions requested, e.g., openid for identity)
• state (random string to prevent CSRF attacks—see Authentication Security)
• code_challenge (Parameter for PKCE, see PKCE (Proof Key for Code Exchange))
• code_challenge_method=S256 (Parameter for PKCE, see PKCE (Proof Key for Code Exchange))

The request endpoint requires the client to authenticate in the same way that the token endpoint requires authentication. You can authenticate in one of the following methods:

1. Use the client_id and client_secret in the Authorization header. The client_id and client_secret are combined, separated by a “:” character and base64 encoded. Example: Authorization: Basic ${BASE64(CLIENT_ID + ":" + CLIENT_SECRET)}.
2. The client_id and client_secret are submitted as parameters in the body of the POST request.
3. Using Private Key JWT authentication, the client_id, a client_assertion composed of a generated and signed JWT and the parameter client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer are all submitted as parameters in the body of the POST request.

Example URL:

POST AUTHORIZATION_SERVER_URL/request
Content-Type: application/x-www-form-urlencoded

client_id=CLIENT_ID
&client_secret=CLIENT_SECRET
&redirect_uri=CALLBACK_URI
&response_type=code
&scope=openid%20profile
&state=XYZ

Notes:

• API_ENVIRONMENT could be something like digital.garden-fi.com
• REQUEST_ENDPOINT could be something like /a/consumer/api/v0/oidc/request

With these two examples, you would send the request to https://digital.garden-fi.com/a/consumer/api/v0/oidc/request

The server validates the request and returns the request_uri:

{
 "request_uri": "REQUEST_URI",
 "expires_in": 60
}

2. Authorization Request

The client’s backend directs the user’s browser to the Jack Henry Authorization Server. This URL includes:

• client_id (application identifier)
• request_uri (obtained from step 1)

Example URL:

https://API_ENVIRONMENT/AUTHENTICATION_ENDPOINT
 ?client_id=CLIENT_ID
 &request_uri=REQUEST_URI

Notes:

• API_ENVIRONMENT could be something like digital.garden-fi.com
• AUTHENTICATION_ENDPOINT could be something like /a/consumer/api/v0/oidc/auth

With these two examples, you would send the request to https://digital.garden-fi.com/a/consumer/api/v0/oidc/auth

3. User Authentication & Consent

The user logs in to Jack Henry’s Authentication Framework. They see a consent screen listing the requested permissions (scopes). The user must explicitly approve or deny access.

4. Authorization Code Issued

After the user consents, they are redirected back to your backend with an authorization code. The redirect looks like this:

https://REDIRECT_URI/?code=AUTH_CODE&state=XYZ&iss=ISSUER

• REDIRECT_URI: The configured redirect URI.
• code: A single-use, temporary credential issued by the Authorization Server. Your backend exchanges this code for an access token (and other tokens) in the Token Exchange step.
• state: The same random, unique string you generated and sent in the authorization request. Receiving this exact same value provides protection against CSRF attacks. Always validate that the returned state matches the one you originally set.
• iss: Short for issuer. This identifies which Authorization Server (e.g., Jack Henry’s) issued the authorization code. In an OpenID Connect flow, iss is typically used to verify the origin of tokens and ensure they come from a trusted authority.

5. Token Exchange (Confidential Clients)

The client exchanges the authorization code for an access token by making a POST request:

POST https://API_ENVIRONMENT/TOKEN_ENDPOINT
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=AUTH_CODE
&redirect_uri=CALLBACK_URI
&client_id=CLIENT_ID
&client_secret=CLIENT_SECRET

Notes:

• API_ENVIRONMENT could be something like digital.garden-fi.com
• TOKEN_ENDPOINT could be something like /a/consumer/api/v0/oidc/token
• code_verifier (Parameter for PKCE, see PKCE (Proof Key for Code Exchange))

With these two examples, you would send the request to https://digital.garden-fi.com/a/consumer/api/v0/oidc/token

The server validates and returns the access token (and ID token, if requested):

{
  "access_token": "ACCESS_TOKEN",
  "id_token": "ID_TOKEN",
  "expires_in": 600,
  "token_type": "Bearer",
  "refresh_token": "REFRESH_TOKEN"
}