Package Instance

Globus `identity_provider` restriction ignored when used with `allow_all` in JupyterHub 5.0
JupyterHub < 5.0, when used with `GlobusOAuthenticator`, could be configured to allow all users from a particular institution only. The configuration for this would look like:

```python

Auth0OAuthenticator has an Authentication Bypass via Unverified Email Claims
### Summary

An authentication bypass vulnerability in `oauthenticator` allows an attacker with an unverified email address on an Auth0 tenant to login to JupyterHub. When `email` is used as the usrname_claim, this gives users control over their username and the possibility of account takeover.

### Impact

This is an **Authentication Bypass Vulnerability**. Any Auth0 tenant leveraging the `Auth0OAuthenticator` mapping the `email` claim to the JupyterHub username is impacted. By default, Auth0 handles email verification as a user flag, not a hard block to authentication streams. If an attacker can register an account with the Auth0 tenant with an unverified email and knows the email of an existing user on the system, they can authenticate as that user.

### Patches

- Upgrade oauthenticator to 17.4

### Workarounds

- Check `email_verified` field in an `Authenticator.post_auth_hook` function
- Do not use `email` as the username claim
- [Enforce email verification in auth0](https://support.auth0.com/center/s/article/Enforce-Email-Verification-With-Sending-Email-After-Each-Denied-Access)

GoogleOAuthenticator.hosted_domain incorrectly verifies membership of an Google organization/workspace
[`GoogleOAuthenticator.hosted_domain`] is used to restrict what Google accounts can be authorized to access a JupyterHub. The restriction _is intended_ to ensure Google accounts are part of one or more Google organizations/workspaces verified to control specified domain(s).

The vulnerability is that the actual restriction has been to Google accounts with emails ending with the domain. Such accounts could have been created by anyone which at one time was able to read an email associated with the domain. This was described by Dylan Ayrey (@dxa4481) in this [blog post] from 15th December 2023.