* 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>
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.
* 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
It isn't used in any providers and we have future plans
to remove the specialness of PreferredUsername and make it
an optional field in the session.
User, Email & Groups will eventually be the only first class
fields on the session that are always set.
* 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
* Add -user-id-claim to support other claims than email
Fix#431 - This is a minimal change to allow the user to configure which claim is
the source of the "user ID".
- Add the option `user-id-claim` (defaults to email)
- OIDC extracts this claim into session.Email (to be renamed later)
- providers: add `CreateSessionStateFromBearerToken` with a default impl taken from
`GetJwtSession` and overridden by oidc to respect `user-id-claim`
Once #466 is merged, I can continue to rename SessionState.Email to .UserID
and add HTTP headers with a corresponding name.
* Apply suggestions from code review
Co-Authored-By: Joel Speed <Joel.speed@hotmail.co.uk>
* Review feedback: Don't extract claims manually
Instead, parse them twice - it might be sligtly slower but less bug-prone as the code evolves.
* Fix indentation
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
* Add support for preferred username.
* Add missing TOC entries.
* Add note about preferred_username support.
* Adjust tests.
* Check on not implemented error for GetPreferredUsername() call.
Co-authored-by: Felix Fontein <felix@fontein.de>
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
Add a new provider for Bitbucket,
can be configured from the options
specifying team and/or repository
that the user must be part/have access
to in order to grant login.
* first stab at login.gov provider
* fixing bugs now that I think I understand things better
* fixing up dependencies
* remove some debug stuff
* Fixing all dependencies to point at my fork
* forgot to hit save on the github rehome here
* adding options for setting keys and so on, use JWT workflow instead of PKCE
* forgot comma
* was too aggressive with search/replace
* need JWTKey to be byte array
* removed custom refresh stuff
* do our own custom jwt claim and store it in the normal session store
* golang json types are strange
* I have much to learn about golang
* fix time and signing key
* add http lib
* fixed claims up since we don't need custom claims
* add libs
* forgot ioutil
* forgot ioutil
* moved back to pusher location
* changed proxy github location back so that it builds externally, fixed up []byte stuff, removed client_secret if we are using login.gov
* update dependencies
* do JWTs properly
* finished oidc flow, fixed up tests to work better
* updated comments, added test that we set expiresOn properly
* got confused with header and post vs get
* clean up debug and test dir
* add login.gov to README, remove references to my repo
* forgot to remove un-needed code
* can use sample_key* instead of generating your own
* updated changelog
* apparently golint wants comments like this
* linter wants non-standard libs in a separate grouping
* Update options.go
Co-Authored-By: timothy-spencer <timothy.spencer@gsa.gov>
* Update options.go
Co-Authored-By: timothy-spencer <timothy.spencer@gsa.gov>
* remove sample_key, improve comments related to client-secret, fix changelog related to PR feedback
* github doesn't seem to do gofmt when merging. :-)
* update CODEOWNERS
* check the nonce
* validate the JWT fully
* forgot to add pubjwk-url to README
* unexport the struct
* fix up the err masking that travis found
* update nonce comment by request of @JoelSpeed
* argh. Thought I'd formatted the merge properly, but apparently not.
* fixed test to not fail if the query time was greater than zero
- Save both user and email in session state:
Encoding/decoding methods save both email and user
field in session state, for use cases when User is not derived from
email's local-parth, like for GitHub provider.
For retrocompatibility, if no user is obtained by the provider,
(e.g. User is an empty string) the encoding/decoding methods fall back
to the previous behavior and use the email's local-part
Updated also related tests and added two more tests to show behavior
when session contains a non-empty user value.
- Added first basic GitHub provider tests
- Added GetUserName method to Provider interface
The new GetUserName method is intended to return the User
value when this is not the email's local-part.
Added also the default implementation to provider_default.go
- Added call to GetUserName in redeemCode
the new GetUserName method is used in redeemCode
to get SessionState User value.
For backward compatibility, if GetUserName error is
"not implemented", the error is ignored.
- Added GetUserName method and tests to github provider.
See the README for usage with Dex or any other OIDC provider.
To test run a backend:
python3 -m http.server
Run dex and modify the example config with the proxy callback:
go get github.com/coreos/dex/cmd/dex
cd $GOPATH/src/github.com/coreos/dex
sed -i.bak \
's|http://127.0.0.1:5555/callback|http://127.0.0.1:5555/oauth2/callback|g' \
examples/config-dev.yaml
make
./bin/dex serve examples/config-dev.yaml
Then run the oauth2_proxy
oauth2_proxy \
--oidc-issuer-url http://127.0.0.1:5556/dex \
--upstream http://localhost:8000 \
--client-id example-app \
--client-secret ZXhhbXBsZS1hcHAtc2VjcmV0 \
--cookie-secret foo \
--email-domain '*' \
--http-address http://127.0.0.1:5555 \
--redirect-url http://127.0.0.1:5555/oauth2/callback \
--cookie-secure=false
Login with the username/password "admin@example.com:password"
* New SessionState to consolidate email, access token and refresh token
* split ServeHttp into individual methods
* log on session renewal
* log on access token refresh
* refactor cookie encription/decription and session state serialization
