… the actor is creating an account or returning to sign in through account access, and already holds a trusted, verified identity with an external provider such as Google, Apple, enterprise SSO, or other identification system. Signing in through that provider spares them creating a password for one more artifact.
Problem
Creating new credentials for every artifact is tedious and increases security risks, but delegating identity to third parties introduces provider lock-in, tracking concerns, and account duplication when returning actors forget which provider they used.
Forces
- Frictionless entry vs platform dependency: one-click sign-in avoids password creation, but ties the actor’s access to the standing of their third-party account and provider availability.
- Permission transparency vs quick onboarding: actors hesitate when third-party sign-in dialogues request wide data access; interfaces that clearly disclose minimal required scopes build trust.
- Provider fragmentation: returning actors frequently forget which provider they originally used, resulting in accidental duplicate accounts and fragmented state.
Delegating identity assertion to an existing provider removes the cognitive friction of inventing new passwords and managing resets. It also leverages multi-factor authentication already configured on the provider account. However, third-party authentication fails when it is implemented as an unexamined collection of branded buttons without clear account reconciliation. When an actor who previously registered with an email later clicks “Sign in with Google” using that same email, treating them as a stranger spawns duplicate accounts and strands their previous work.
Solution
Allow actors to assert identity via established external identity providers: request only essential scopes, state requested permissions clearly, and link accounts by verified email address to prevent duplicate accounts.
Keep the list of providers focused and relevant to the artifact’s domain. When a returning actor authenticates with a provider that matches an existing verified email, merge the identities or prompt for confirmation rather than creating an isolated second profile.
Continuation
The actor authenticates with a single gesture through their existing provider, without creating or maintaining standalone credentials. Where the actor prefers direct communication tokens without third-party platform coupling, passwordless access provides the alternative…
All connections
- Enables
- Account access — The actor is creating an account or returning to sign in through account access, and already holds a trusted, verified identity with an external provider such as Google, Apple, enterprise SSO, or other identification system.
- Enacts
- Agency — lets the actor choose an existing trusted identity provider rather than creating redundant credentials
- Shareability — connects the actor's workspace identity to standard cross-platform identity tokens
- Alternatives
- Passwordless access — Where the actor prefers direct communication tokens without third-party platform coupling, passwordless access provides the alternative
- Password — Signing in through that provider spares them creating a password for one more artifact.
In practice
Scope disclosure
Request only the minimal identity scopes necessary for authentication: the verified email address and basic profile identifier. State clearly beside the provider buttons what the artifact will and will not access.
Account reconciliation
When an incoming provider token carries an email address that matches an existing registered account, reconcile them gracefully. If the existing account uses a password, prompt the actor to sign in with their password once to link the Google or GitHub identity permanently, rather than silently failing or overwriting the profile.
Resources & references
- UI Patterns: Social Login
- Vitaly Friedman (2022). Authentication UX Design Guidelines