oauth2-proxy/.gitignore
Braunson ce750e9b30
PKCE Support (#1541)
* 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>
2022-03-13 10:08:33 +00:00

44 lines
576 B
Plaintext

oauth2-proxy
vendor
dist
release
.godeps
*.exe
.env
.bundle
c.out
# Go.gitignore
# Compiled Object files, Static and Dynamic libs (Shared Objects)
*.o
*.a
*.so
# Folders
_obj
_test
.idea/
.vscode/
# Architecture specific extensions/prefixes
*.[568vq]
[568vq].out
*.cgo1.go
*.cgo2.c
_cgo_defun.c
_cgo_gotypes.go
_cgo_export.*
_testmain.go
# Editor swap/temp files
.*.swp
# Dockerfile.dev is ignored by both git and docker
# for faster development cycle of docker build
# cp Dockerfile Dockerfile.dev
# vi Dockerfile.dev
# docker build -f Dockerfile.dev .
Dockerfile.dev