Migrations/neko
1
0
Fork 0
mirror of https://github.com/m1k1o/neko.git synced 2026-11-03 00:11:48 -06:00
Code Issues Packages Projects Releases Wiki Activity

oauth: ignore email when provider reports email_verified=false.

Browse Source 
An unverified email could match admin_emails/user_emails on providers that
let users set their own email. Only an explicit false is rejected; providers
that omit the claim are still trusted. Document the behavior.

Reported-by: Zachariah Mithani <zachariah@aplosai.com> (AploSec)
This commit is contained in:
Miroslav Šedivý
2026-10-28 17:05:56 +01:00
parent 92f99168b8
commit 23d8a2718e
4 changed files with 47 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
webpage/docs/configuration/authentication.md
+4
View File
@@ -234,6 +234,10 @@ The sign-in endpoint is `GET /api/oauth/login`; the callback endpoint is `GET /a
`admin_emails` and `user_emails` are matched against the `email` claim. Most providers only include that claim if the `email` scope is requested, so `scopes` must include `"email"` (in addition to `"openid"`) or the claim will be empty and these lists will never match.
:::
:::warning
If the provider returns `email_verified: false`, Neko ignores the email, so it cannot match `admin_emails` or `user_emails`. If the claim is missing, the email is trusted, because many providers (including generic OAuth2 providers such as GitHub) do not return it at all. In that case `admin_emails` and `user_emails` rely on the identity provider having verified the address. If users can register or edit their email without verification on a provider that does not send `email_verified`, anyone could claim an address listed in `admin_emails` and obtain an administrator session. Require email verification at the provider or do not use these lists.
:::
For OAuth sessions, `GET /api/whoami` includes `extra_data`: the merged userinfo and ID-token claims, with userinfo values taking precedence. It is returned only to the authenticated session owner and is intended for profile-field troubleshooting. Do not place secrets in provider profile claims.
For non-OIDC providers, set `authorization_url`, `token_url`, `userinfo_url`, and optionally `redirect_url` directly. For GitHub, for example, use `read:user` as a scope and set `subject_field: id`, `username_field: login`, and `avatar_field: avatar_url`.