When using GitHub OAuth together with the configuration option:
USER_EMAIL_ALLOWED_DOMAINS
Taiga may reject valid users because the GitHub authentication logic appears to use the first email returned by the GitHub API rather than the primary email associated with the GitHub account.
GitHub returns a list of emails from /user/emails with metadata fields such as primary and verified. However Taiga seems to select the first email instead of explicitly selecting the primary one.
This makes USER_EMAIL_ALLOWED_DOMAINS unreliable when users have multiple verified emails.
Example GitHub account:
GitHub API response example:
[
{ "email": "user@gmail.com", "primary": false, "verified": true },
{ "email": "user@udc.es", "primary": true, "verified": true }
]If Taiga selects the first email (user@gmail.com), login fails when using:
USER_EMAIL_ALLOWED_DOMAINS = ["udc.es"]
because the domain check is performed against gmail.com.
Expected behavior
Taiga should select the primary verified email.
primary == true
This issue particularly affects environments such as universities or companies where users frequently have multiple email addresses linked to their GitHub accounts.
Taiga requires the user:email scope to retrieve emails from GitHub during OAuth authentication.
How can we reproduce the behavior
Configure Taiga with GitHub OAuth:
ENABLE_GITHUB_AUTH=True
PUBLIC_REGISTER_ENABLED=True
USER_EMAIL_ALLOWED_DOMAINS=["udc.es"]
Use a GitHub account that has multiple verified emails:
Attempt login via GitHub OAuth.
If GitHub returns gmail.com first in /user/emails, Taiga rejects login even though the primary email belongs to the allowed domain.
Workarounds
Current workarounds are limited:
- Removing secondary emails from the GitHub account
- Allowing additional domains (e.g. gmail.com)
- Patching Taiga backend locally
These are not ideal for institutional deployments where domain restrictions are required.
Screenshots
Not applicable (authentication flow issue).
Taiga environment
- Self-hosted Taiga.
- Deployment method: taiga-docker
- Reverse proxy: nginx / nginx proxy manager
- GitHub OAuth configured following the official documentation.
- Desktop:
- OS: Linux
- Browser: Chrome
- Version: 145
Additional context
This issue impacts deployments where administrators rely on:
USER_EMAIL_ALLOWED_DOMAINS
to restrict access (for example universities restricting access to institutional email domains).
Selecting the GitHub primary verified email instead of the first email returned by the API would make the behavior deterministic and consistent with user expectations.
When using GitHub OAuth together with the configuration option:
USER_EMAIL_ALLOWED_DOMAINSTaiga may reject valid users because the GitHub authentication logic appears to use the first email returned by the GitHub API rather than the primary email associated with the GitHub account.
GitHub returns a list of emails from
/user/emailswith metadata fields such asprimaryandverified. However Taiga seems to select the first email instead of explicitly selecting the primary one.This makes
USER_EMAIL_ALLOWED_DOMAINSunreliable when users have multiple verified emails.Example GitHub account:
GitHub API response example:
[ { "email": "user@gmail.com", "primary": false, "verified": true }, { "email": "user@udc.es", "primary": true, "verified": true } ]If Taiga selects the first email (user@gmail.com), login fails when using:
USER_EMAIL_ALLOWED_DOMAINS = ["udc.es"]because the domain check is performed against gmail.com.
Expected behavior
Taiga should select the primary verified email.
primary == trueThis issue particularly affects environments such as universities or companies where users frequently have multiple email addresses linked to their GitHub accounts.
Taiga requires the user:email scope to retrieve emails from GitHub during OAuth authentication.
How can we reproduce the behavior
Configure Taiga with GitHub OAuth:
Use a GitHub account that has multiple verified emails:
Attempt login via GitHub OAuth.
If GitHub returns gmail.com first in /user/emails, Taiga rejects login even though the primary email belongs to the allowed domain.
Workarounds
Current workarounds are limited:
These are not ideal for institutional deployments where domain restrictions are required.
Screenshots
Not applicable (authentication flow issue).
Taiga environment
Additional context
This issue impacts deployments where administrators rely on:
USER_EMAIL_ALLOWED_DOMAINSto restrict access (for example universities restricting access to institutional email domains).
Selecting the GitHub primary verified email instead of the first email returned by the API would make the behavior deterministic and consistent with user expectations.