AdminUI OpenIddict with PAR Support

AdminUI OpenIddict PAR Support

OpenIddict 6.1 introduced support for making Pushed Authorization Requests (PAR). This can be done on a client-by-client level or a global level. With this update, AdminUI for OpenIddict released a new version 3.0 that supports OpenIddict 6.1, and with it, configuring PAR options on a client level.

What is PAR?

PAR is an OAuth 2.0 spec. It outlines a mechanism in OAuth for clients to directly push authorization requests in interactive flows to authorization servers in return for a URI, which is used to reference this authorization request data in later requests.

Using PAR allows authorization requests to be initiated via a backchannel rather than a redirect in the frontend user agent. This means parameters like redirect_uri, response_type, state, etc can be sent down a more secure route in exchange for a URI that references this data to be used in the frontend redirect.

This is also a benefit if your initial auth redirect in the frontend is a large request with all the authorization parameters used. You swap the request parameters for a client_id and  a request_uri that references this data.

Another benefit of using PAR is that if used with confidential clients in OpenIddict, you can ensure that only clients with valid credentials can initiate an authentication/authorization flow when PAR is enforced. This could be done using the client secret or the client assertions in OpenIddict.

Configuring PAR With AdminUI

First, we need an instance of AdminUI and OpenIddict running. We have an article that goes into how you can achieve this using a dotnet template to have a solution up and running quickly.

You will also need to make some slight modifications to the OpenIddict project in the generated template to enable PAR. You will need to specify a PAR endpoint; you can do this by appending .SetPushedAuthorizationEndpointUris(“connect/par”) to the fluent method call starting on line 110 of the Startup.cs file in the OpenIddict project.

Next, you will need to have a client to test configuring PAR for in AdminUI. For this I will be using the OpenIddict sample Velusia.Client. Once you have this ready, modify the client configuration on line 102 of the Startup.cs file so it looks similar to the following code:

Initially, disabling PAR to show the setting takes effect when you make changes to the configuration in AdminUI.

Now we need to configure the Velusia client in AdminUI. To do this, navigate to the client’s page in AdminUI and click ‘Add Client’. You can now configure it as follows:

• Type: Web App
• Client Id: testing_par
• Display Name: Testing PAR
• Callback URL: https://localhost:44338/callback/login/local
• Logout URL: https://localhost:44338/callback/logout/local
• Scopes to Add: User Profile

Once configured, click the created client in the list view to navigate to the edit screens, then go to the Advanced->PAR tabs. Here you should see two options related to PAR:

• The endpoint permission
• Whether PAR should be required for this client

On this page select the option to require PAR, then save the changes. You will notice that this has automatically enabled the PAR endpoint option and disabled it, since you will need the endpoint permission for a client to require the use of PAR.

Now if you run your Velusia client sample and try to login you should see that you get an error. This error will say that the authorization requires a request_uri parameter. This is because we have disabled PAR in the client. To resolve this, go back into the sample and reconfigure the client to enable PAR by changing the ‘DisablePushedAuthorizationRequest’ to false and relaunch the sample.

Now if you try to login, you should successfully be directed through the login flow and arrive at the prompt page. It will ask you to give permission to the client to access the scopes requested. If you look at the URL when you get there, you should see a ‘request_uri’ parameter set instead of the normal auth request parameters.

In OpenIddict you can specify the requirement for PAR at a global level too using the .RequirePushedAuthorizationRequests() method on the OpenIddictServerBuilder. This will however leave the setting configured on a client level redundant, so if you do experience issues with PAR always required no matter the client config this may be the culprit.

What’s Next in AdminUI for OpenIddict

We want to work on improving the configuration setting screens in the advanced section to move endpoint and lifetime permission into places they have a relative connection to, rather than grouping them like we have currently.

Now that we have PAR support in OpenIddict it makes sense to make AdminUI support PAR when it authenticates with OpenIddict.

We are also looking to move over features that we have in the Duende IdentityServer version of the product that are not tethered to IdentityServer, and that would have a usefulness in the OpenIddict version of the product.

If you are looking for a feature-rich, enterprise-grade product, follow Joe Harvey's AdminUI's QuickStart guide or Jerrie Pelsers' third-party introductory look into AdminUI.