DEV Community

WinslowKnight8469
WinslowKnight8469

Posted on

Community Account Linking Under Provider Exit (Proof Before Accidental Identity Mutation)

#authentication #security #community

Short answer: community account linking should mutate an existing member only after a fresh, independent proof controls both identities; matching email addresses are a discovery hint, never proof, and a managed-provider exit is the right moment to make that invariant explicit.

For an education community, the hard case is not the ordinary sign-in. It is the learner who used a school identity last term, a personal identity this term, and then asks for GDPR deletion while both browser and mobile sessions still exist. A platform that equates “same email” with “same person” can merge two people before deletion, revoke the wrong sessions, or retain an external login that can recreate access. I would therefore block the migration on one measurable condition: every account mutation must be explainable by evidence recorded before the mutation, and deletion must close every session path attached to the internal member ID.

No guesswork.

What evidence keeps community account linking from merging distinct identities?

Start with two records that have different jobs. A member is the community's durable subject: profile, moderation history, course participation, consent, and deletion state belong there. An external identity is a login credential bound to that subject. Its stable key is the pair of issuer and subject supplied by the identity system, not a display name and not an email address. OWASP's authentication guidance likewise separates a user ID from mutable identifiers and recommends reauthentication for sensitive account changes.

That distinction matters during a provider migration because email has several ambiguous states. It may be absent, unverified, reassigned by an organization, spelled with provider-specific aliases, or shared through an operational mailbox. Even a verified email establishes that a provider verified control under its own process; it does not establish that two currently authenticated principals should become one community member. Automatic matching silently converts weak correlation into authority.

The safe flow is deliberately inconvenient. When the signed-in learner asks to add another login, create a short-lived link intent bound to the current internal member, require fresh authentication with the candidate identity, and present the resulting relationship for confirmation. The server then consumes the intent once, verifies that the candidate identity is not attached elsewhere, writes an audit event, and commits the link in one transaction. If the candidate is already attached to another member, return a conflict and route the case to account recovery or human review; do not detach and reattach it as a convenience.

I use three evidence classes when reviewing this path: possession of the active member session, fresh proof from the identity being added, and an explicit linking intent with a narrow lifetime. The exact lifetime depends on the threat model and login latency; I'm not sure a single number travels well across passkeys, enterprise federation, and email-based recovery. What resolves that uncertainty is telemetry: measure completion time, expiration rate, replay attempts, and the age of the session that initiated linking, then set a bound that fits the service's risk budget rather than copying a magic value.

The SLO is also sharper than “login works.” Track unauthorized-link reports as a security invariant, link conflicts by reason, and the percentage of accepted links with all three evidence records. Availability cannot compensate for a false merge. One wrong merge is an integrity event.

The data model is the migration boundary

A clean schema makes the provider replaceable. Keep members under community ownership; store external identities in a child table with a unique constraint on (issuer, subject); store sessions against the internal member ID; and keep link intents and immutable audit events separately. Provider tokens do not belong in the member row. This arrangement lets the authentication adapter change while moderation, enrollment, and deletion continue to address the same internal subject.

The preventative path below is intentionally a domain service, not a callback handler. All provider-specific parsing has already produced a verified Principal. The transaction locks both the intent and relevant identity key, so two concurrent confirmations cannot attach the same principal twice.

package accountlink

import (
    "context"
    "errors"
    "time"
)

var (
    ErrExpired  = errors.New("link intent expired")
    ErrConflict = errors.New("external identity already linked")
)

type Principal struct {
    Issuer  string
    Subject string
}

type LinkIntent struct {
    ID        string
    MemberID  string
    ExpiresAt time.Time
    UsedAt    *time.Time
}

type Tx interface {
    LockIntent(context.Context, string) (LinkIntent, error)
    MemberForIdentity(context.Context, Principal) (string, bool, error)
    InsertIdentity(context.Context, string, Principal) error
    MarkIntentUsed(context.Context, string, time.Time) error
    AppendAudit(context.Context, string, string, Principal, time.Time) error
}

type Store interface {
    WithinTransaction(context.Context, func(Tx) error) error
}

func Confirm(ctx context.Context, store Store, intentID string, candidate Principal, now time.Time) error {
    return store.WithinTransaction(ctx, func(tx Tx) error {
        intent, err := tx.LockIntent(ctx, intentID)
        if err != nil {
            return err
        }
        if intent.UsedAt != nil || !now.Before(intent.ExpiresAt) {
            return ErrExpired
        }

        memberID, found, err := tx.MemberForIdentity(ctx, candidate)
        if err != nil {
            return err
        }
        if found && memberID != intent.MemberID {
            return ErrConflict
        }
        if !found {
            if err := tx.InsertIdentity(ctx, intent.MemberID, candidate); err != nil {
                return err
            }
        }
        if err := tx.AppendAudit(ctx, intent.MemberID, "identity.linked", candidate, now); err != nil {
            return err
        }
        return tx.MarkIntentUsed(ctx, intent.ID, now)
    })
}
Enter fullscreen mode Exit fullscreen mode

There are two details worth testing under load. First, database uniqueness is the final concurrency guard even if the application checks first. Second, a retry after a lost response must observe a consumed intent and return a stable outcome rather than execute a second mutation. I would inject contention around the same (issuer, subject) pair and around the same intent ID, because a happy-path unit test cannot expose the race that matters.

Do not normalize two issuers into one because their hostnames look related. Issuer aliases need an explicit, reviewed migration mapping. The same caution applies to subjects: opaque values stay opaque, including strings that happen to resemble email addresses.

How should deletion revoke sessions for the same internal subject?

Account linking is only half the lifecycle. In the GDPR deletion scenario, the deletion command should first transition the internal member to a non-interactive state, then revoke every session indexed by that member ID, invalidate outstanding link and recovery intents, and queue the bounded erasure or anonymization work required by the community's retention policy. Authentication checks must reject the member state before accepting an otherwise valid session. That ordering closes the gap where a session remains usable while asynchronous cleanup walks external identities.

Make deletion idempotent. A repeated request should converge on the same terminal state, not recreate jobs or fail because one identity was already removed. Record progress by phase, and alert on age against a deletion completion SLO. The target should be derived from the legal and product commitments actually made by the service; inventing a stricter number in an engineering article would be theater.

The migration rehearsal needs adversarial fixtures, not a count comparison. Include two members who share an email, one member with two issuers, one external identity already linked elsewhere, a consumed intent, a deletion racing with a link confirmation, and active sessions on multiple devices. Run the old and new resolution logic in shadow mode without allowing the shadow path to mutate state, compare decisions by internal member ID, and stop rollout on any unexplained merge or resurrection after deletion. Capacity planning belongs here too: size the revocation index and deletion queue for the burst created by a school or cohort leaving, and verify that the oldest job age stays inside the operational objective during that burst.

A concrete review question keeps this honest: after a member enters deletion, can any credential, recovery token, link intent, or session resolve to an interactive subject? If the answer depends on which provider issued it, the migration boundary is still leaking.

Should a community buy identity linking or build the control plane?

The decision is not managed versus self-hosted in the abstract. It is where the team wants to own identity evidence, concurrency, auditability, session indexing, and deletion orchestration. Auth0, Amazon Cognito, and Keycloak are useful examples of distinct operating models, but their presence does not remove the need for an application-owned subject and explicit merge policy. Product configuration also changes, so verify current behavior in the primary documentation during evaluation rather than treating a comparison table as a contract.

Decision area Managed service Self-hosted component Application-owned layer
Authentication protocols Less protocol operations for the team More upgrade and on-call ownership Keep a narrow adapter boundary
Link authorization May provide provider-specific flows Policy remains yours to configure Best place for explicit dual proof and consent
Session revocation Often shaped by service session semantics Full control, plus storage and incident load Index sessions by the internal member
Deletion workflow External identity cleanup is only one phase You operate the full dependency chain Coordinate state, revocation, retention, and audit
Migration leverage Faster start, higher dependency on export semantics Easier source inspection, heavier operations Stable subject IDs reduce both forms of lock-in

My default would be to buy standards-heavy authentication mechanics and own the linking policy plus internal subject mapping. The catch is on-call capacity: a small team with no identity specialist should not self-host a security-sensitive protocol stack merely to feel independent. Stick with a managed service when its export, deletion, and session controls satisfy tested exit criteria and the reduced operational load is worth the dependency. Conversely, a regulated deployment that requires infrastructure isolation or a custom credential boundary may justify self-hosting, provided the team budgets patching, key rotation, upgrades, backup recovery, and incident response as recurring work rather than migration-only tasks.

Before signing or renewing, run an exit drill. Export a representative set of identities, reconstruct mappings in a staging environment, replay link conflicts, revoke sessions by internal member, and complete a deletion without calling provider-specific logic from the community domain. The pass condition is boring: no ambiguous ownership, no accidental merge, no resurrected subject, and an audit record for every accepted mutation.

That is the practical selection rule. Choose the operating model whose failure modes the team can detect and own, while keeping identity resolution and account lifecycle semantics inside the community boundary.

References

Top comments (0)