* Issue 2016: CVE-2022-41717: DoS in Go net/http may lead to DoS
* Issue 2016: CVE-2022-41717: DoS in Go net/http may lead to DoS
* Issue 2016: CVE-2022-41717: DoS in Go net/http may lead to DoS
* Issue 2016: CVE-2022-41717: DoS in Go net/http may lead to DoS
* Issue 2016: CVE-2022-41717: DoS in Go net/http may lead to DoS
* Issue 2016: CVE-2022-41717: DoS in Go net/http may lead to DoS
* Issue 2016: CVE-2022-41717: DoS in Go net/http may lead to DoS
* Issue 2016: CVE-2022-41717: DoS in Go net/http may lead to DoS
* Issue 2016: CVE-2022-41717: DoS in Go net/http may lead to DoS
* Issue 2016: CVE-2022-41717: DoS in Go net/http may lead to DoS
---------
Co-authored-by: Nuno Borges <Nuno.Borges@ctw.bmwgroup.com>
* Log the difference between invalid email and not authorized session
* Add changelog entry
* Remove superfluous argument
---------
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
* Ensure sign-in page background is uniform throughout the page
Configured banners that take up large amounts of space leave a gap of blank
background between where the body ends and the footer starts. Fix this by
setting the style for the section containing the banner to match the body and
footer
* Add changelog entry
---------
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
* Issue 1929: Oauth2-proxy v7.4.0 is not using alpine:3.16 as it is written in code & updates versions due to fixed CVEs
* Issue 1929: Oauth2-proxy v7.4.0 is not using alpine:3.16 as it is written in code & updates versions due to fixed CVEs
* Fixes CVE-2022-41721 (#1994)
See: https://avd.aquasec.com/nvd/2022/cve-2022-41717/
* update checkout actions (#1981)
* Fix a typo in oauthproxy.go (#2021)
* fix typo (#2001)
* Issue 1929: Oauth2-proxy v7.4.0 is not using alpine:3.16 as it is written in code & updates versions due to fixed CVEs
* Issue 1929: Oauth2-proxy v7.4.0 is not using alpine:3.16 as it is written in code & updates versions due to fixed CVEs
* Issue 1929: Oauth2-proxy v7.4.0 is not using alpine:3.16 as it is written in code & updates versions due to fixed CVEs
* Issue 1929: Oauth2-proxy v7.4.0 is not using alpine:3.16 as it is written in code & updates versions due to fixed CVEs
* Issue 1929: Oauth2-proxy v7.4.0 is not using alpine:3.16 as it is written in code & updates versions due to fixed CVEs
* Issue 1929: Oauth2-proxy v7.4.0 is not using alpine:3.16 as it is written in code & updates versions due to fixed CVEs
* Issue 1929: Oauth2-proxy v7.4.0 is not using alpine:3.16 as it is written in code & updates versions due to fixed CVEs
---------
Co-authored-by: Nuno Borges <Nuno.Borges@ctw.bmwgroup.com>
Co-authored-by: Jeroen Landheer <jlandheer@bintelligence.nl>
Co-authored-by: Ryuichi Watanabe <ryucrosskey@gmail.com>
Co-authored-by: Ho Kim <ho.kim@ulagbulag.io>
Co-authored-by: Terrell Russell <terrellrussell@gmail.com>
* feat: readiness check
* fix: no need for query param
* docs: add a note
* chore: move the readyness check to its own endpoint
* docs(cr): add godoc
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
* Fix uninitialized user claim
Some providers doesn't initialize data with setProviderDefaults function
(keycloak-oidc for example), therefore UserClaim is never initialized
with the default value and stay as an empty string.
This result in an empty user.
* Add CHANGELOG.md entry for #1873
* Call setProviderDefaults where missing
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
* Update go-redis/redis to v9.
- And updated redislock, testify, ginko and gomega have also been updated.
- Renamed the option `IdleTimeout` to `ConnMaxIdleTime` because of 517938a6b0/CHANGELOG.md
* Update CHANGELOG.md
* Dropping dot import of the types since they created aliases now
* fixing some error messages to make tests happy
* updating more error messages that were changed to make tests happy
* reverting error messages
Co-authored-by: Muhammad Arham <marham@i2cinc.com>
* Avoid Nextcloud "Current user is not logged in" (Statuscode 997)
The error message results from oauth2-proxy trying to pass the
access token via URL. Instead it needs to be sent via header,
thus the Nextcloud provider requires a fix similar to what #1502
did before for the keycloak provider.
* Implement EnrichSession() for Nextcloud provider
Parse nested JSON to transform relevant information (groups, id,
email) from the OAuth2 userinfo endpoint into session.
* Update CHANGELOG.md (add link to PR #1750)
* Add API route config
In addition to requests with Accept header `application/json` return 401 instead of 302 to login page on requests matching API paths regex.
* Update changelog
* Refactor
* Remove unnecessary comment
* Reorder checks
* Lint Api -> API
Co-authored-by: Sebastian Halder <sebastian.halder@boehringer-ingelheim.com>
* dynamically update the htpasswdMap based on the changes made to the htpasswd file
* added tests to validate that htpasswdMap is updated after the htpasswd file is changed
* refactored `htpasswd` and `watcher` to lower cognitive complexity
* returned errors and refactored tests
* added `CHANGELOG.md` entry for #1701 and fixed the codeclimate issue
* Apply suggestions from code review
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
* Fix lint issue from code suggestion
* Wrap htpasswd load and watch errors with context
* add the htpasswd wrapped error context to the test
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
* Inconsistent code-challenge-method CLI flag and config file naming
- Allow previous config option for now to prevent breaking configs
Fixes#1667
* Add changelog entry
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
* Fix vulnerabilities on crypto, net and sys packages and change go version on Docker builder stage
* Changelog related PR $1774
Co-authored-by: Felipe Bonvicini Conti <felipe.conti@totvs.com.br>
* adding IdleTimeout with the redis-connection-idle-timeout flag, to keep redis connections in valid state, when Redis option is set
* docs update - add redis idle timeout configurations
* changelog update for #1691 fix
* 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>
* 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>
* 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 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>
