I'm having the same problem. Unable to solve it so far.
@johnmiller @maburns @zradick did you manage to get past this problem, and if so, how?
Thanks for any advice!

OK so I was finally able to track it down fix it. Some short notes below, maybe it helps anyone else running into the same problem.
Thanks to @mark-robustelli and @dan for their inputs.

1. I accessed FusionAuth directly on port 9011, completely bypassing the reverse proxy
2. In the CORS filter config, I activated "Debug enabled" which in the system logs showed me java.lang.IllegalArgumentException: Illegal character in authority at index 7 and java.lang.NullPointerException: Cannot read field "actionURI" because "actionInvocation" is null
3. Going from there, I completely disabled the CORS filter
4. This immediately got rid of the 403 and everything worked again, accessing FA using the reverse proxy
5. The FA UI told me that I'm missing two headers in my reverse proxy config: X-Forwarded-Proto and X-Forwarded-Port, which I then configured (https/443 in my case)
6. After that I enabled the CORS filter again (all default values) and since, everything is working correctly, like before

OK so I was finally able to track it down fix it. Some short notes below, maybe it helps anyone else running into the same problem.
Thanks to @mark-robustelli and @dan for their inputs.

1. I accessed FusionAuth directly on port 9011, completely bypassing the reverse proxy
2. In the CORS filter config, I activated "Debug enabled" which in the system logs showed me java.lang.IllegalArgumentException: Illegal character in authority at index 7 and java.lang.NullPointerException: Cannot read field "actionURI" because "actionInvocation" is null
3. Going from there, I completely disabled the CORS filter
4. This immediately got rid of the 403 and everything worked again, accessing FA using the reverse proxy
5. The FA UI told me that I'm missing two headers in my reverse proxy config: X-Forwarded-Proto and X-Forwarded-Port, which I then configured (https/443 in my case)
6. After that I enabled the CORS filter again (all default values) and since, everything is working correctly, like before

@mark-robustelli Unfortunately not. I've tried it several times, with different browsers (to make sure it's not a cache issue etc.). It seems that when logging in, the page https://<myurl>/oauth2/authorize (which results in a 403) is not really logging me in. If afterwards I go to https://<myurl>/admin/application or https://<myurl>/admin/tenant, I'm still redirected to the login form.

I really would like to see FusionAuth's application logs, I'm pretty sure I'd see something there why the 403 occurs. Is there really no way? I need to get this issue fixed.

@mark-robustelli Unfortunately, no. We're running FusionAuth in a Docker container. For that scenario, the doc says "When running FusionAuth on Docker or other container service where logs are written to stdout and not written to the file system, this API will return an empty archive.".

Here's some info about our setup.

• FA behind nginx reverse proxy, docker based. 3 environments (dev, staging, production). Has been working for many months without trouble.
• A few days ago, upgraded FA in the DEV env, from 1.28 to 1.47.1
• Since then, when trying to log into FA, the POST request to /oauth2/authorize is responded by a blank page (HTTP 403)
• Tried a lot of stuff, but to no avail so far. We're using the recommended nginx config (https://github.com/FusionAuth/fusionauth-contrib/blob/master/Reverse Proxy Configurations/nginx/nginx.ssl.conf)
• For debugging purposes, I've built up a 4th environment with the exact same setup (nginx reverse proxy and FA). The FA installation (1.47.1) was installed from scratch. The problem is not showing in that environment.
• This leads to the suspicion that the 403 could be related to existing data/config in the existing installation. But which? And how to access logs, when not being able to log into FA?
• The logs in stdout of the FA container are not anything related to the error.

Any ideas? How can I see logs of why FA decides for a 403 in /oauth2/authorize ?

I'm having the same problem. Unable to solve it so far.
@johnmiller @maburns @zradick did you manage to get past this problem, and if so, how?
Thanks for any advice!