🐛 Bug Report: CORS error for accessing the userinfo endpoint using a web client #113

New Issue

AtHeartEngineer · 2025-07-08T08:40:11-04:00

AtHeartEngineer commented

2025-07-08 08:40:11 -04:00

Originally created by @simonfranken on 6/2/2025

Reproduction steps

Create an OIDC provider with the options Public Client and PKCE Enabled.
Configure a web frontend (in my case, Vue.js with oidc-client-ts) for using Pocket ID as the identity provider.
After successful authentication, the package attempts to retrieve the user information using the userinfo endpoint of Pocket ID and sends the obtained token via the Authorization header.
However, the response from Pocket ID does not permit the Authorization header due to a CORS error.

Expected behavior

The Pocket ID should permit the Authorization header to be included at the very least for clients that are configured as Public.
I conducted the following tests:

I configured Pocket ID behind a Nginx reverse proxy, which adds the Access-Control-Allow-Headers: * header to all responses. This header resolves the issue in my specific case. However, it is important to note that this is merely a workaround, as the inclusion of this header should not be applied to all responses.

Actual Behavior

Pocket ID sends a response, which does not allow the Authorization header.

Version and Environment

v1.0

Log Output

No response

*Originally created by @simonfranken on 6/2/2025* ### Reproduction steps * Create an OIDC provider with the options `Public Client` and `PKCE Enabled`. * Configure a web frontend (in my case, Vue.js with [oidc-client-ts](https://authts.github.io/oidc-client-ts/)) for using Pocket ID as the identity provider. * After successful authentication, the package attempts to retrieve the user information using the userinfo endpoint of Pocket ID and sends the obtained token via the `Authorization` header. * However, the response from Pocket ID does not permit the `Authorization` header due to a CORS error. ### Expected behavior The Pocket ID should permit the Authorization header to be included at the very least for clients that are configured as Public. I conducted the following tests: * I configured Pocket ID behind a Nginx reverse proxy, which adds the `Access-Control-Allow-Headers: *` header to all responses. This header resolves the issue in my specific case. However, it is important to note that this is merely a workaround, as the inclusion of this header should not be applied to all responses. ### Actual Behavior Pocket ID sends a response, which does not allow the `Authorization` header. ### Version and Environment v1.0 ### Log Output _No response_

AtHeartEngineer closed this issue

2025-07-08 08:40:11 -04:00

AtHeartEngineer added the bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug labels 2025-07-08 08:40:12 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/pocket-id#113