…)"

This reverts commit 9c61c49.

…)"

This reverts commit 9c61c49.

## Why This Revert is Necessary

The original fix broke nginx deployments using `auth_request`. When `/oauth2/auth` returns 302,
nginx's `auth_request` module treats this as an internal error:

    [error] auth request unexpected status: 302 while sending to client

nginx then returns **500 Internal Server Error** to the browser.

## Root Cause

The nginx `auth_request` module has strict semantics (non-negotiable):

| Subrequest status | nginx behavior |
|---|---|
| 2xx | Allow request |
| 401 / 403 | Deny → trigger `error_page` |
| **Any other status** | **Internal error → 500** |

The `/oauth2/auth` endpoint is used as a **policy oracle** (yes/no decision),
not as a browser-facing endpoint. It cannot return redirects.

## User Impact

Any nginx deployment with:
- `skip-provider-button=true`
- Using `auth_request` directive

Will receive 500 errors instead of the expected authentication flow.

## The Correct Solution

The correct fix for oauth2-proxy#334 is a **documentation update**, not a code change:

```nginx
error_page 401 = @oauth2_signin;

location @oauth2_signin {
    return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;
}
```

This keeps `/oauth2/auth` as a pure 401/2xx oracle and lets nginx perform the proper 302 redirect to the browser.

## Related

- Original Issue: oauth2-proxy#334
- Broken PR: oauth2-proxy#3309

Signed-off-by: Stefan Markmann <stefan@markmann.net>

)"

This reverts commit 9c61c49.

The original fix broke nginx deployments using `auth_request`. When `/oauth2/auth` returns 302,
nginx's `auth_request` module treats this as an internal error:

    [error] auth request unexpected status: 302 while sending to client

nginx then returns **500 Internal Server Error** to the browser.

> If the subrequest returns a 2xx response code, the access is allowed. If it returns 401 or 403,
> the access is denied with the corresponding error code. Any other response code returned by the
> subrequest is considered an error.
https://nginx.org/en/docs/http/ngx_http_auth_request_module.html

The nginx `auth_request` module has strict semantics (non-negotiable):

| Subrequest status | nginx behavior |
|---|---|
| 2xx | Allow request |
| 401 / 403 | Deny → trigger `error_page` |
| **Any other status** | **Internal error → 500** |

The `/oauth2/auth` endpoint is used as a **policy oracle** (yes/no decision),
not as a browser-facing endpoint. It cannot return redirects.

Any nginx deployment with:
- `skip-provider-button=true`
- Using `auth_request` directive

Will receive 500 errors instead of the expected authentication flow.

The correct fix for oauth2-proxy#334 is a **documentation update**, not a code change:

```nginx
error_page 401 = @oauth2_signin;

location @oauth2_signin {
    return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;
}
```

This keeps `/oauth2/auth` as a pure 401/2xx oracle and lets nginx perform the proper 302 redirect to the browser.

- Original Issue: oauth2-proxy#334
- Regression introduced in PR: oauth2-proxy#3309

Signed-off-by: Stefan Markmann <stefan@markmann.net>
Signed-off-by: Jan Larwig <jan@larwig.com>

This reverts commit 9c61c49.

The original fix broke nginx deployments using `auth_request`. When `/oauth2/auth` returns 302,
nginx's `auth_request` module treats this as an internal error:

    [error] auth request unexpected status: 302 while sending to client

nginx then returns **500 Internal Server Error** to the browser.

> If the subrequest returns a 2xx response code, the access is allowed. If it returns 401 or 403,
> the access is denied with the corresponding error code. Any other response code returned by the
> subrequest is considered an error.
https://nginx.org/en/docs/http/ngx_http_auth_request_module.html

The nginx `auth_request` module has strict semantics (non-negotiable):

| Subrequest status | nginx behavior |
|---|---|
| 2xx | Allow request |
| 401 / 403 | Deny → trigger `error_page` |
| **Any other status** | **Internal error → 500** |

The `/oauth2/auth` endpoint is used as a **policy oracle** (yes/no decision),
not as a browser-facing endpoint. It cannot return redirects.

Any nginx deployment with:
- `skip-provider-button=true`
- Using `auth_request` directive

Will receive 500 errors instead of the expected authentication flow.

The correct fix for #334 is a **documentation update**, not a code change:

```nginx
error_page 401 = @oauth2_signin;

location @oauth2_signin {
    return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;
}
```

This keeps `/oauth2/auth` as a pure 401/2xx oracle and lets nginx perform the proper 302 redirect to the browser.

- Original Issue: #334
- Regression introduced in PR: #3309

Signed-off-by: Stefan Markmann <stefan@markmann.net>
Signed-off-by: Jan Larwig <jan@larwig.com>
Co-authored-by: Jan Larwig <jan@larwig.com>