* Unbreak oauth2-proxy for keycloak provider after 2c668a

With 2c668a, oauth2-proxy fails a request if the token validation fails.
Token validation always fails with the keycloak provider, due to the
valudation request passing the token via the URL, and keycloak not
parsing the url for tokens.

This is fixed by forcing the validation request to pass the token via a
header.

This code taken from the DigitalOcean provider, which presumably forcing
the token to be passed via header for the same reason.

Test plan: I was unable to build a docker image to test the fix, but I
believe it is relatively simple, and it passes the "looks good to me"
test plan.

* Add changelog entry for unbreak keycloak

Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>

The correct URL for the oidc-issuer-url in KeyCloak v18.0 is: https://<keycloak host>/realms/<your realm>. 
Using the old URL causes oauth2-proxy to crash on startup.

Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>

* Add redirect instructions for gitlab on sub-dir

* include redirect instructions in unversioned docs

Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>

* Fixes typo in repo endpoint

* Update CHANGELOG.md

* Fix the test to mock the correct endpoint

Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>

* add docs on ipv6

* add tests for ipv6 address

* add tests for ipv6 address

* remove Print function for debugging

* Updated changelog

* Change error type for redirect parsing errors

This changes the error type returned when the proxy fails to parse the
redirect target to be a 400 error instead of a 500 error.

As far as I can tell, the only way that this can fail is a failure to
parse the properties of the request to identity the redirect target.
This indicates that the user has sent a malformed request, and so should
result in a 400 rather than a 500.

I've added a test to exercise this, based on a real work example.

* Update changelog

Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>

Configure upstream timeout

Signed-off-by: Jack Henschel <jack.henschel@cern.ch>

CVE fixes pertaining to text, crypto and prometheus

* Add allowed_emails option to the auth endpoint query string

* Don't return true from checkAllowedEmailsOrDomains only because domains field was empty

* Fix checkAllowedEmailsOrDomains logic

* Added tests for allowed_emails query parameter

* Updated CHANGELOG

* Remove checkAllowedEmailsOrDomains

Co-authored-by: Nick Meves <nicholas.meves@gmail.com>

* Build ARMv8 Docker Images

Fixes #1593

* Change platform to arm64/v8

* Drop separate tags for different architectures

* Mark the architecture image tags for deprecation

Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>

* Use distroless debian11 docker image

* Add `Dockerfile` to `.dockerignore`

* Replace `nonroot` with the matching UID/GID
Alpine does not have that user, and it cause issues when trying to start the container

* Use a build arg for setting the runtime image

* Explain why `ARG RUNTIME_IMAGE` is at the top

* Add entry to CHANGELOG

* Move build-arg to `DOCKER_BUILDX_ARGS`

Add groups to session too when creating session from bearer token

* Add the allowed_email_domains and the allowed_groups on the auth_request endpoint + support standard wildcard char for validation with sub-domain and email-domain.

Signed-off-by: Valentin Pichard <github@w3st.fr>

* Fix provider data initialisation

* PKCE Support

Adds Code Challenge PKCE support (RFC-7636) and partial
Authorization Server Metadata (RFC-8414) for detecting PKCE support.

- Introduces new option `--force-code-challenge-method` to force a
specific code challenge method (either `S256` or `plain`) for instances
when the server has not implemented RFC-8414 in order to detect
PKCE support on the discovery document.
- In all other cases, if the PKCE support can be determined during discovery
then the `code_challenge_methods_supported` is used and S256 is always
preferred.
- The force command line argument is helpful with some providers like Azure
who supports PKCE but does not list it in their discovery document yet.
- Initial thought was given to just always attempt PKCE since according to spec
additional URL parameters should be dropped by servers which implemented
OAuth 2, however other projects found cases in the wild where this causes 500
errors by buggy implementations.
See: https://github.com/spring-projects/spring-security/pull/7804#issuecomment-578323810
- Due to the fact that the `code_verifier` must be saved between the redirect and
callback, sessions are now created when the redirect takes place with `Authenticated: false`.
The session will be recreated and marked as `Authenticated` on callback.
- Individual provider implementations can choose to include or ignore code_challenge
and code_verifier function parameters passed to them

Note: Technically speaking `plain` is not required to be implemented since
oauth2-proxy will always be able to handle S256 and servers MUST implement
S256 support.
> If the client is capable of using "S256", it MUST use "S256", as "S256"
> is Mandatory To Implement (MTI) on the server.  Clients are permitted
> to use "plain" only if they cannot support "S256" for some technical
> reason and know via out-of-band configuration that the server supports
> "plain".
Ref: RFC-7636 Sec 4.2

oauth2-proxy will always use S256 unless the user explicitly forces `plain`.

Fixes #1361

* Address PR comments by moving pkce generation

* Make PKCE opt-in, move to using the Nonce generater for code verifier

* Make PKCE opt-in, move to using the Nonce generater for code verifier

* Encrypt CodeVerifier in CSRF Token instead of Session

- Update Dex for PKCE support
- Expose HTTPBin for further use cases

* Correct the tests

* Move code challenges into extra params

* Correct typo in code challenge method

Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>

* Correct the extra space in docs

Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>

* Address changelog and new line nits

* Add generated docs

Co-authored-by: Valentin Pichard <github@w3st.fr>
Co-authored-by: Joel Speed <joel.speed@hotmail.co.uk>

main: fix typo "convert-config-to-alpha"

docs/configuration: Fix entropy for bash secret

Ensure docs release action has correct env

Filtering `/dev/urandom` for alphanumeric characters resulted in loss of
input entropy to base64. Fixing this using a procedure with these steps:

  * Read 32 bytes from `/dev/urandom` (`dd`)
  * Base64-encode (`base64`)
  * Strip newlines (`tr -d`)
  * URL-Escape (`tr`)
  * Append a final newline (`echo`)

This output should be equivalent to output generated using Python and
OpenSSL variants mentioned in the changed document file.

Newlines are stripped as `base64` wraps its output and the option to
disable this (`-w 0`) is not available in all implementations.

Fixes: #1511

Update Docusaurus to 2.0.0-beta.15

Update the list of flags obsoleted by alpha config

Pass URL parameters from /oauth2/start through to IdP login URL

You must explicitly configure oauth2-proxy (alpha config only) with which parameters are allowed to pass through, and optionally provide an allow-list of valid values and/or regular expressions for each one.  Note that this mechanism subsumes the functionality of the "prompt", "approval_prompt" and "acr_values" legacy configuration options, which must be converted to the equivalent YAML when running in alpha config mode.

Introduce ProviderVerifier to clean up OIDC discovery code