If an OICD App is created or edited into an invalid state, it should not become undeleteable/uneditable. #394

New issue

Closed

opened 2026-05-04 13:29:45 -05:00 by fehho · 3 comments

fehho commented

2026-05-04 13:29:45 -05:00

(Migrated from github.com)

Describe the bug:

When using end-point GET /api/admin/client/{client_key} where client_key refers to a client left in an invalid state, a 400 was returned. In the web UI, this prevents editing the OIDC App to correct the configuration, or even deleting the app to to free the client key and replace with a new configuration.

To Reproduce:

Create an OICD App using the web UI
Still in the web UI, change configuration to use only a http (unsecure) redirect, response types id_token, token, and grant types authorization_code, refresh_token
Hit update, afterwards do or don't use a clean web UI session as this process leaves the web UI generally unstable
a. Visit Web UI /admin/client/your_client_id and see 'Error loading OIDC App Details.'
b. use Web UI to click delete button of your client and see 'Could not delete app.'

Expected behavior:

API and/or web UI should attempt to provide graceful degradation so that a recovery may be made in the general case of an invalid OIDC App configuration.

Database Driver:

DB_ADAPTER: postgres # this is the default value

Screenshots:

Image of a successful reproduction

Additional context:

Additionally, investigating and resolving the specific case given in reproduction step 2 could be considered. A 400 is returned to the PATCH request, but persistent changes are still made.

### Describe the bug: When using end-point GET `/api/admin/client/{client_key}` where client_key refers to a client left in an invalid state, a 400 was returned. In the web UI, this prevents editing the OIDC App to correct the configuration, or even deleting the app to to free the client key and replace with a new configuration. ### To Reproduce: 1. Create an OICD App using the web UI 2. Still in the web UI, change configuration to use only a http (unsecure) redirect, response types id_token, token, and grant types authorization_code, refresh_token 3. Hit update, afterwards do or don't use a clean web UI session as this process leaves the web UI generally unstable 4. a. Visit Web UI /admin/client/your_client_id and see 'Error loading OIDC App Details.' b. use Web UI to click delete button of your client and see 'Could not delete app.' ### Expected behavior: API and/or web UI should attempt to provide graceful degradation so that a recovery may be made in the general case of an invalid OIDC App configuration. ### Database Driver:  DB_ADAPTER: postgres # this is the default value ### Screenshots:  Image of a successful reproduction <img width="1192" height="1998" alt="Image" src="https://github.com/user-attachments/assets/25cf215d-0d4b-4d9d-bc4a-7e4f2cf38a3c" /> ### Additional context:  Additionally, investigating and resolving the specific case given in reproduction step 2 could be considered. A 400 is returned to the PATCH request, but persistent changes are still made.

😕 1

notquitenothing commented

2026-05-07 14:58:15 -05:00

(Migrated from github.com)

I will take a look at this when I get the chance

notquitenothing commented

2026-05-10 14:44:53 -05:00

(Migrated from github.com)

Thank you for opening this issue, I am able to replicate the problem. I have a tentative fix that may be released soon, it appears the issue is caused by two things.

The oidc-provider package sometimes builds OIDC clients differently than their saved metadata. When this happens after validation, a client may be validated+saved successfully but future instantiations of the same client will fail. This is happening when response types=id_token, token, and grant types=authorization_code, refresh_token, this client will be retrieved having grant types=implicit, refresh_token. I assume this is because the grant types imply an implicit flow, but this is opaque to me and happens inside the oidc-provider package. Implicit grant clients may not use insecure protocols, as the error suggests.
Client metadata retrieval is dependent on being able to build a valid client. This should not be the case, and is what is causing you not to be able to edit or delete an invalid client.

The fix will address both of these problems. I will start by validating (again) the client metadata after is has been saved and rolling back update if the validation fails either time, and also decoupling the client response retrieval from the oidc-provider package allowing the update or deletion of invalid clients.

Thank you for opening this issue, I am able to replicate the problem. I have a tentative fix that may be released soon, it appears the issue is caused by two things. 1. The oidc-provider package sometimes builds OIDC clients differently than their saved metadata. When this happens after validation, a client may be validated+saved successfully but future instantiations of the same client will fail. This is happening when `response types=id_token, token`, and `grant types=authorization_code, refresh_token`, this client will be retrieved having `grant types=implicit, refresh_token`. I assume this is because the grant types imply an implicit flow, but this is opaque to me and happens inside the oidc-provider package. Implicit grant clients may not use insecure protocols, as the error suggests. 2. Client metadata retrieval is dependent on being able to build a valid client. This should not be the case, and is what is causing you not to be able to edit or delete an invalid client. The fix will address both of these problems. I will start by validating (again) the client metadata _after_ is has been saved and rolling back update if the validation fails either time, and also decoupling the client response retrieval from the oidc-provider package allowing the update or deletion of invalid clients.

❤️ 1

fehho commented

2026-05-10 22:16:05 -05:00

(Migrated from github.com)

Fix was able to be verified. Thank you for resolving the issue!

❤️ 1