Missing CORS prevents OIDC Authorization Code Flow with PKCE for applications #2278

silwol commented 2025年12月30日 09:19:47 +01:00

Comment

I'm implementing a single page app that will run in the browser. The development happens on codeberg, and we will host our own instance of the app. Authentication happens through OIDC in an Authorization Code Flow with PKCE.

The authorization procedure appears to work as expected, e.g. when using GitLab as an OIDC provider. The plan is to use Codeberg as an OIDC provider for our own instance of the app though (because that's where the project lives anyway), and there the request from the browser to the https://codeberg.org/login/oauth/access_token POST endpoint fails with Reason: CORS Missing Allow Origin.

I set up a local Forgejo instance with very permissive CORS headers for testing (in this case a reverse proxy hands out the CORS headers), and the access token fetch works well there as well.

Not sure where exactly the CORS headers for the codeberg.org instance are added, whether it's Forgejo itself or the reverse proxy. I hope my use case is not too unusual, but still I would be surprised if I'm the first person to be affected by this. Please let me know if this is something that should be addressed directly to the Forgejo project. At a first glance this appears to be related to configuration more than the Forgejo implementation, because e.g. on https://v14.next.forgejo.org the browser already prevents access to the /.well-known/openid-configuration GET endpoint due to missing CORS headers.

### Comment I'm implementing a single page app that will run in the browser. The development [happens on codeberg](https://codeberg.org/pib), and we will host our own instance of the app. Authentication happens through OIDC in an Authorization Code Flow with PKCE. The authorization procedure appears to work as expected, e.g. when using GitLab as an OIDC provider. The plan is to use Codeberg as an OIDC provider for our own instance of the app though (because that's where the project lives anyway), and there the request from the browser to the `https://codeberg.org/login/oauth/access_token` **POST** endpoint fails with **Reason: CORS Missing Allow Origin**. I set up a local Forgejo instance with very permissive CORS headers for testing (in this case a reverse proxy hands out the CORS headers), and the access token fetch works well there as well. Not sure where exactly the CORS headers for the codeberg.org instance are added, whether it's Forgejo itself or the reverse proxy. I hope my use case is not too unusual, but still I would be surprised if I'm the first person to be affected by this. Please let me know if this is something that should be addressed directly to the Forgejo project. At a first glance this appears to be related to configuration more than the Forgejo implementation, because e.g. on <https://v14.next.forgejo.org> the browser already prevents access to the `/.well-known/openid-configuration` **GET** endpoint due to missing CORS headers.

Gusted commented 2026年01月05日 15:01:11 +01:00

fetch("https://codeberg.org/login/oauth/access_token", {method: 'POST'});

In the browser console just works. I would need more information from you on how you are doing these requests to properly help you, but CORS is definitely enabled for this endpoint.

```js fetch("https://codeberg.org/login/oauth/access_token", {method: 'POST'}); ``` In the browser console just works. I would need more information from you on how you are doing these requests to properly help you, but CORS is definitely enabled for this endpoint.

silwol commented 2026年01月05日 19:41:08 +01:00

Thanks for looking into this!

Attempting to build a reproducer, I discovered that the POST endpoint works just fine when sent with the code in your example.

I found a reproducer though, it shows that the failure happens when the browser sends a pre-flight CORS request with the OPTIONS method.

It appears that this pre-flight request is triggered if requests have certain properties (in this case, it appears to be the Authorization header).

Reproducer:

fetch("https://codeberg.org/login/oauth/access_token", { method: 'POST', headers: { "Authorization": "Bearer abcdef" }});

Thanks for looking into this! Attempting to build a reproducer, I discovered that the `POST` endpoint works just fine when sent with the code in your example. I found a reproducer though, it shows that the failure happens when the browser sends a [pre-flight CORS request with the `OPTIONS` method](https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request). It appears that this pre-flight request is triggered if requests have [certain properties](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS#preflighted_requests) (in this case, it appears to be the `Authorization` header). Reproducer: ```js fetch("https://codeberg.org/login/oauth/access_token", { method: 'POST', headers: { "Authorization": "Bearer abcdef" }}); ```

Gusted commented 2026年01月06日 11:02:42 +01:00

And in your code you set This Authorization? If so, why? This will indeed not work.

And in your code you set This Authorization? If so, why? This will indeed not work.

silwol commented 2026年01月06日 20:58:55 +01:00

Well, I didn't intentionally, but it looks like the OIDC library I'm using does, and I didn't question that... 🤦

A quick test injecting a client into the request function that strips out the Authorization header shows that the authentication flow works just fine and does not trigger the pre-flight request. Time to look for a clean solution to that.

Thanks a lot for your patience, your support, and finally for the Codeberg service!

Closing this issue.

Well, I didn't intentionally, but it looks like the OIDC library I'm using does, and I didn't question that... 🤦 A quick test injecting a client into the request function that strips out the `Authorization` header shows that the authentication flow works just fine and does not trigger the pre-flight request. Time to look for a clean solution to that. Thanks a lot for your patience, your support, and finally for the Codeberg service! Closing this issue.