Destructive Identity Operations Explained: Login-Method Removal and Full User Deletion

Short answer: treat login-method removal as a recoverable credential change, but treat full user deletion as an irreversible, observable workflow that revokes every session before personal data is erased. The page says gdpr_delete_stuck, and the on-call view is uncomfortable: the identity row is gone, yet the session-validity probe still accepts a refresh token issued before deletion. For a fintech system, that is not a housekeeping delay. The user can still reach an account that the control plane reports as deleted, while the support team no longer has a clean identity record from which to investigate or recover it. The least complex safe design is a per-user revocation fence plus an idempotent deletion coordinator. Set the fence first, reject all older sessions at every authorization boundary, preserve a minimal tombstone for replay safety and audit obligations, and then fan out erasure work. Login-method removal uses the same careful ordering, but it must leave at least one verified recovery path or stop before mutation. Those two operations may share screens and tables; they should not share semantics. What should destructive identity operations guarantee for login-method removal and full user deletion? A destructive identity operation needs an explicit postcondition. “The database call returned 204” is an implementation detail, not a security result. For login-method removal, the postcondition is that the named authenticator can no longer start a session and the account still has an approved way back in. For full deletion, the postcondition is that no existing session can authorize a request, no new session can be issued, personal data has entered a bounded erasure workflow, and retries cannot resurrect the principal. This distinction matters because recovery changes the threat model. Removing a password from an account that still has a verified passkey may be routine. Removing the last passkey from an account whose recovery email is unverified creates an account-lockout path. A full deletion request is different again: keeping a hidden “recovery login” after deletion would contradict the user's request, but immediately destroying every trace can make retries, fraud holds, financial-record retention, and proof of erasure impossible to reason about. GDPR Article 17 includes exceptions to erasure, including compliance with a legal obligation and the establishment, exercise, or defense of legal claims; the data model therefore needs field-level retention decisions rather than a single deleted boolean. The security boundary is session acceptance, not row existence. OAuth 2.0 token revocation defines a way to invalidate a token and, where applicable, related tokens. OpenID Connect back-channel logout defines a server-to-server logout signal. Neither removes the need for a local authorization check when tokens are self-contained and may remain cryptographically valid until expiry. A per-user revoked_before timestamp or monotonically increasing session generation gives each service a cheap comparison it can enforce even while asynchronous cleanup continues. Account recovery deserves its own capacity review. Every additional recovery path enlarges the attack surface; every removed path raises lockout and support load. OWASP recommends reauthentication after high-risk events and treating sensitive account changes as high-risk actions. NIST's authentication guidance also treats account recovery as part of authenticator lifecycle management, not an informal escape hatch. So require a recent, phishing-resistant step where available, notify through an independent channel after a login method changes, and do not let possession of the method being removed serve as the only proof for adding its replacement. Work backward from the page The deletion page is a lagging signal. The earlier signal should have been a divergence between the revocation fence and successful authorization: count requests accepted for a subject when the token issue time is older than that subject's revoked_before, and page on any sustained nonzero rate. This is one of the rare ratios where a tiny denominator should not excuse the event. One accepted request after the fence is a correctness breach; a backlog of downstream erasure tasks is an availability and compliance risk with a time budget. Instrument the workflow as a state machine rather than a pile of log messages. A useful trace carries an opaque operation ID, pseudonymous subject ID, initiation reason, actor class, current state, attempt count, and timestamps for the revocation fence and each required erasure acknowledgment. Do not put email addresses, access tokens, recovery codes, or raw government identifiers into labels or spans. High-cardinality operation IDs belong in traces and structured logs; metrics should use bounded dimensions such as state, dependency class, and outcome. The on-call runbook can then ask concrete questions in order: Is the subject disabled and is the revocation fence visible at every authorization decision point? Are new credentials, refresh tokens, and recovery challenges blocked for that subject? Which deletion state is waiting, and is retry ownership unambiguous? Is retained data covered by a documented legal or fraud-control basis, with access restricted accordingly? Has the user-facing operation reached its promised completion state, even if separately governed backups age out later? No guessing. The instrumentation change is small but structural: emit the fence version on both the mutation span and the authorization span, then compare them. Alert separately on security invariant violations, workflow age, and retry exhaustion. If all three are collapsed into “deletion errors,” a slow analytics erasure can wake the security on-call while an actually accepted stale session hides in the same aggregate. Put revocation before erasure The coordinator should make the irreversible work repeatable. The following Go sketch omits transport and storage details on purpose; the contract is the useful part. FenceSessions must be durable before any worker receives the deletion event, each handler must treat the operation ID as an idempotency key, and the coordinator must never interpret a retry as permission to recreate a missing identity. package identity import ( "context" "errors" "time" ) var ErrLastRecoveryPath = errors.New("cannot remove the last verified recovery path") type Store interface { VerifiedRecoveryPaths(ctx context.Context, userID string) (int, error) DisableLoginMethod(ctx context.Context, userID, methodID string) error FenceSessions(ctx context.Context, userID, operationID string, at time.Time) error DisableIdentity(ctx context.Context, userID, operationID string) error WriteTombstone(ctx context.Context, userID, operationID string) error } type ErasureBus interface { Publish(ctx context.Context, operationID, userID string) error } type Service struct { store Store bus ErasureBus now func() time.Time } func (s *Service) RemoveLoginMethod( ctx context.Context, userID, methodID string, ) error { paths, err := s.store.VerifiedRecoveryPaths(ctx, userID) if err != nil { return err } if paths <= 1 { return ErrLastRecoveryPath } return s.store.DisableLoginMethod(ctx, userID, methodID) } func (s *Service) DeleteUser( ctx context.Context, userID, operationID string, ) error { if err := s.store.FenceSessions(ctx, userID, operationID, s.now()); err != nil { return err } if err := s.store.DisableIdentity(ctx, userID, operationID); err != nil { return err } if err := s.store.WriteTombstone(ctx, userID, operationID); err != nil { return err } return s.bus.Publish(ctx, operationID, userID) } Enter fullscreen mode Exit fullscreen mode There is a hard edge here — publication and database mutation need a transactional outbox, or an equivalent atomic handoff, in a real deployment. Otherwise the process can commit the disabled identity and exit before the event is durable. Workers should acknowledge only after their local deletion transaction commits, store the idempotency key with that transaction, and return a stable success result when the same operation arrives again. Retries need exponential backoff and jitter, but retry policy cannot substitute for an owner, a maximum workflow age, and a dead-letter review path. Self-contained access tokens also force a choice. Very short expirations reduce the window but increase token-exchange load and do not produce immediate revocation. Online introspection or a session-generation lookup closes the window but adds latency and a high-availability dependency to authorization. A cached generation can reduce load, although its maximum staleness becomes part of the revocation SLO. Capacity planning should model peak authenticated request rate, cache-miss rate, and identity-store failure behavior before the fence becomes mandatory across services. Choose recovery and deletion semantics deliberately The buy-versus-build question is less about a feature checkbox than about which system owns the invariant. Managed identity can reduce credential-handling work, while the application still owns fintech ledgers, support records, analytics copies, notification history, and retention policy. Self-hosting can expose more control over session checks and event delivery, but it also puts key rotation, abuse defenses, upgrades, and 24-hour on-call coverage on the platform team. Don't count only implementation weeks; count the pager. Decision Managed control plane Self-hosted control plane SRE question Session revocation Provider mechanism plus application enforcement Locally designed fence and enforcement Can every resource server reject a pre-fence token within the SLO? Recovery methods Configured provider flows and policy hooks Full lifecycle and abuse controls owned internally Can the last verified path be detected before mutation? Deletion fan-out Identity deletion is one step in a wider workflow Identity and workflow are both operated internally Who owns retries across every personal-data store? Audit evidence Export and retention boundaries must be verified Schema, access, and retention are internal duties Can evidence be retained without retaining unnecessary personal data? Lock-in Migration depends on export and protocol boundaries Migration depends on internal schemas and operations Can credential identifiers and subject mappings move safely? The catch is that a synchronous cascade is not suitable when downstream systems have different availability targets or statutory retention rules; use an asynchronous coordinator with a visible deadline instead. An asynchronous workflow is not suitable for the session boundary, however, because “eventually logged out” is the wrong guarantee after full user deletion. Keep the fence synchronous and the erasure fan-out asynchronous. I'm not sure there is a universal safe completion threshold for the whole erasure workflow. The right number depends on the published user promise, backup architecture, processor contracts, and applicable retention duties. What is universal is the need to declare that threshold before launch, measure its tail rather than its average, and assign an escalation owner when the remaining budget is consumed. Test the invariants, then tune the alert Test with generated identities and pseudonymous fixtures. A deletion conformance test should mint multiple sessions, initiate deletion twice with the same operation ID, race a refresh request against the fence, replay every worker message, and verify that all authorization checks reject tokens issued before the fence. For login-method removal, exercise a user with two verified methods, a user with exactly one, concurrent removal requests, and a recovery method that loses verification between read and commit. The last case is why the “at least one path remains” rule belongs in a transaction or compare-and-swap, not only in UI validation. Deployment should start with observation: calculate the would-reject decision beside the existing authorization result, compare it in telemetry without exposing subject data, and then enforce after every resource server reports the fence version. This is also where a contract test catches services that validate signatures but skip account state. Rollback must not lower a user's fence or re-enable a deleted identity; if application code rolls back, the security state remains monotonic. Set two service objectives. The revocation SLO measures time from accepted destructive request to universal rejection of prior sessions. The erasure-workflow SLO measures time to terminal acknowledgment from all in-scope processors, with legally retained records represented as an explicit terminal state rather than a silent exception. Track p50 for capacity trends and a high percentile for the promise, but page on violated security invariants and rapidly exhausting error budget, not on every ordinary retry. Thresholds have a cost. Page on a single confirmed post-fence authorization, because batching those events trades sleep for unauthorized access. For workflow age, a threshold set too close to normal tail latency turns dependency jitter into repeated pages; set too far away, it consumes the time needed for manual repair before the user promise expires. Use historical latency by dependency class, test injected delay, and review the alert after policy or topology changes. False positives aren't free: they train responders to distrust the one page in this system that must mean “a deleted user can still act.” References OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html GDPR, Article 17, Right to erasure: https://eur-lex.europa.eu/eli/reg/2016/679/oj NIST SP 800-63B, Authentication and authenticator management: https://pages.nist.gov/800-63-4/sp800-63b.html OAuth 2.0 Token Revocation, RFC 7009: https://www.rfc-editor.org/rfc/rfc7009 OpenID Connect Back-Channel Logout 1.0: https://openid.net/specs/openid-connect-backchannel-1_0.html Further reading The sources above are the primary material for authentication changes, recovery, erasure obligations, token revocation, and coordinated logout. Start with the OWASP and NIST guidance for control design, then use RFC 7009 and OpenID Connect Back-Channel Logout to define protocol boundaries.