* Create session cookie when cookie-expire set 0
* Fix format
* add test
* fix lint error
* fix test code
* fix conflicted test case
* update test case of cookie expiration
* update tests of csrf cookies
* update docs
* Update docs/docs/configuration/overview.md
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
---------
Co-authored-by: tanuki884 <morkazuk@fsi.co.jp>
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
* 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>
* Set and verify a nonce with OIDC
* Create a CSRF object to manage nonces & cookies
* Add missing generic cookie unit tests
* Add config flag to control OIDC SkipNonce
* Send hashed nonces in authentication requests
* Encrypt the CSRF cookie
* Add clarity to naming & add more helper methods
* Make CSRF an interface and keep underlying nonces private
* Add ReverseProxy scope to cookie tests
* Align to new 1.16 SameSite cookie default
* Perform SecretBytes conversion on CSRF cookie crypto
* Make state encoding signatures consistent
* Mock time in CSRF struct via Clock
* Improve InsecureSkipNonce docstring
* Encode sessions with MsgPack + LZ4
Assumes ciphers are now mandatory per #414. Cookie & Redis sessions
can fallback to V5 style JSON in error cases. TODO: session_state.go
unit tests & new unit tests for Legacy fallback scenarios.
* Only compress encoded sessions with Cookie Store
* Cleanup msgpack + lz4 error handling
* Change NewBase64Cipher to take in an existing Cipher
* Add msgpack & lz4 session state tests
* Add required options for oauthproxy tests
More aggressively assert.NoError on all
validation.Validate(opts) calls to enforce legal
options in all our tests.
Add additional NoError checks wherever error return
values were ignored.
* Remove support for uncompressed session state fields
* Improve error verbosity & add session state tests
* Ensure all marshalled sessions are valid
Invalid CFB decryptions can result in garbage data
that 1/100 times might cause message pack unmarshal
to not fail and instead return an empty session.
This adds more rigor to make sure legacy sessions
cause appropriate errors.
* Add tests for legacy V5 session decoding
Refactor common legacy JSON test cases to a
legacy helpers area under session store tests.
* Make ValidateSession a struct method & add CHANGELOG entry
* Improve SessionState error & comments verbosity
* Move legacy session test helpers to sessions pkg
Placing these helpers under the sessions pkg removed
all the circular import uses in housing it under the
session store area.
* Improve SignatureAuthenticator test helper formatting
* Make redis.legacyV5DecodeSession internal
* Make LegacyV5TestCase test table public for linter
This helper method is only applicable for Base64 wrapped
encryption since it operated on string -> string primarily.
It wouldn't be used for pure CFB/GCM ciphers. After a messagePack
session refactor, this method would further only be used for
legacy session compatibility - making its placement in cipher.go
not ideal.
Have it take in a cipher init function as an argument.
Remove the confusing `newCipher` method that matched legacy behavior
and returns a Base64Cipher(CFBCipher) -- instead explicitly ask for
that in the uses.
During the upcoming encoded session refactor, AES GCM is ideal
to use as the Redis (and other DB like stores) encryption wrapper
around the session because each session is encrypted with a
distinct secret that is passed by the session ticket.
All Encrypt/Decrypt Cipher implementations will now take
and return []byte to set up usage in future binary compatible
encoding schemes to fix issues with bloat encrypting to strings
(which requires base64ing adding 33% size)
* Refactor the utils package to other areas
Move cookieSession functions to cookie session store
& align the double implementation of SecretBytes to be
united and housed under encryption
* Remove unused Provider SessionFromCookie/CookieForSession
These implementations aren't used, these are handled in the cookie store.
* Add changelog entry for session/utils refactor
