Write down what single sign-on's e-mail matching trusts #62

New issue

Closed

opened 2026-09-06 16:05:55 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-09-06 16:05:55 +00:00

Owner

What the settings do today

SOCIALACCOUNT_EMAIL_AUTHENTICATION = True
SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT = True

Somebody arriving through the configured identity provider is linked to, and signed in as,
the existing local account holding that e-mail address.

This is not a defect, and the audit checked. allauth only matches addresses the
provider marked as verified:

emails = [e.email for e in sociallogin.email_addresses if e.verified]

So an unverified claim links to nothing.

What is worth writing down anyway

The whole security of the arrangement now rests on one property of the operator's chosen
provider: that email_verified: true means the person actually proved they hold the
address. That is true of a well-run Keycloak, Authentik or Pocket ID. It is not
automatically true of every OIDC endpoint somebody might configure, and a provider that
lets a user set their own address and marks it verified turns "sign in with SSO" into
"sign in as anyone whose address you know".

POSTULO_OIDC_AUTO_SIGNUP is off by default, which stops a stranger creating an account —
but linking to an account that already exists is a different door, and it is open by
default.

accounts/social_adapter.py documents what it does about usernames and signup policy and
says nothing about this, which is the gap.

Shape

Hardening gains a paragraph: what Postulo does with a verified address from the
provider, and the one question an operator must be able to answer about their own
provider before turning single sign-on on.
The sign-in settings page says it too, in a sentence, beside the provider fields —
where somebody is when the decision is being made.
A setting for operators who want the stricter behaviour: POSTULO_OIDC_LINK_BY_EMAIL,
default on to preserve today's behaviour, off to require the person to sign in locally
once and connect the provider deliberately.
The adapter's docstring gains the sentence it is missing.

Classification

Documentation, security. Not a vulnerability; not breaking.

Depends on

Nothing. It should land before anything that lets single sign-on stand in for a second
factor, because it establishes what that trust rests on.

## What the settings do today ```python SOCIALACCOUNT_EMAIL_AUTHENTICATION = True SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT = True ``` Somebody arriving through the configured identity provider is linked to, and signed in as, the existing local account holding that e-mail address. **This is not a defect, and the audit checked.** allauth only matches addresses the provider marked as verified: ```python emails = [e.email for e in sociallogin.email_addresses if e.verified] ``` So an unverified claim links to nothing. ## What is worth writing down anyway The whole security of the arrangement now rests on one property of *the operator's chosen provider*: that `email_verified: true` means the person actually proved they hold the address. That is true of a well-run Keycloak, Authentik or Pocket ID. It is not automatically true of every OIDC endpoint somebody might configure, and a provider that lets a user set their own address and marks it verified turns "sign in with SSO" into "sign in as anyone whose address you know". `POSTULO_OIDC_AUTO_SIGNUP` is off by default, which stops a stranger creating an account — but linking to an account that already exists is a different door, and it is open by default. `accounts/social_adapter.py` documents what it does about usernames and signup policy and says nothing about this, which is the gap. ## Shape 1. **Hardening gains a paragraph**: what Postulo does with a verified address from the provider, and the one question an operator must be able to answer about their own provider before turning single sign-on on. 2. **The sign-in settings page says it too**, in a sentence, beside the provider fields — where somebody is when the decision is being made. 3. **A setting for operators who want the stricter behaviour**: `POSTULO_OIDC_LINK_BY_EMAIL`, default on to preserve today's behaviour, off to require the person to sign in locally once and connect the provider deliberately. 4. The adapter's docstring gains the sentence it is missing. ## Classification Documentation, security. Not a vulnerability; not breaking. ## Depends on Nothing. It should land before anything that lets single sign-on stand in for a second factor, because it establishes what that trust rests on.

tiagoagueda added this to the 0.2.0 milestone

2026-09-06 16:05:55 +00:00

tiagoagueda added the

labels

2026-09-06 16:05:55 +00:00

tiagoagueda added a new dependency

2026-09-06 16:05:58 +00:00

#48 Let an administrator waive the second factor for a passkey or an SSO sign-in