* 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>
when type asserting fails here, err is reassigned with nil and the
default block of the switch prints out <nil> in the error message. This
makes debugging a configuration or access token issue difficult
The particular error this surfaces is:
Response: {
"error": "unauthorized_client",
"error_description": "Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested."
}
Signed-off-by: Josh Bielick <jbielick@gmail.com>
* Remove shadowing of predeclared identifier: new.
* strings.ReplaceAll instead of strings.Replace with -1.
* Change strings.ToLower comparison to strings.EqualFold.
* Rewrite if-else-if-else chain as a switch.
* Check Google group membership with hasMember and get.
This PR is an enhancement built on
https://github.com/pusher/oauth2_proxy/pull/160. That PR reduces the
number of calls to the Google Admin API and simplifies the code by
using the hasMember method. It also supports checking membership in
nested groups.
However, the above message doesn't handle members who are not a part
of the domain. The hasMember API returns a 400 for that case. As a
fallback, when the API returns a 400, this change will try using the
`get` API which works as expected for members who aren't a part of the
domain. Supporting members who belong to the Google group but aren't
part of the domain is a requested feature from
https://github.com/pusher/oauth2_proxy/issues/95.
https://developers.google.com/admin-sdk/directory/v1/reference/members/get
Note that nested members who are not a part of the domain will not be
correctly detected with this change.
* Update CHANGELOG.
* Fix incorrect JSON and stop escaping strings.
* Add comments for each scenario.
When checking user membership against Google groups the groups are checked one
at a time and in the order that they were supplied. If one of the groups does
not exist then the checking is halted with the following error.
google.go:201: googleapi: Error 404: Resource Not Found: groupKey, notFound
None of the groups following the missing group are checked either. This means
that something as trivial as a typo in the first group will make it impossible
for anybody to login.
This change catches the 404, logs a message, and then carries on as usual. In
this way a typo will cause a particular group to stop working but will not
affect any other groups.
* 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
