starter.wiki中文

Decision map

Identity

How should the product establish identity, manage account and tenant lifecycle, and control access without conflating proofing, sign-in, and permissions?

Recommendation

Start with Authentication

Application teams designing consumer or B2B identity, account lifecycle, enterprise federation, tenant membership, and wallet-based sign-in.

Open the starting decision

Scope

Use this boundary to avoid solving adjacent problems in the wrong layer.

Included

  • Application authentication and authenticator requirements
  • Account and profile lifecycle management
  • Authorization policy and enforcement ownership
  • Enterprise federation and provisioning
  • B2B tenant, organization, and membership modeling
  • Wallet-address authentication when wallet control is the identity primitive

Excluded

  • Real-world identity proofing and regulated verification, which belong to Security
  • Payment fraud and transaction-risk decisions
  • Generic secrets, audit-log, and application-security controls
  • Social login, passwordless, MFA, roles, and permissions as independent top-level Tasks
1234

Important tools

These tools represent distinct routes inside this decision area; open the relevant Task before treating any as a default.

Decision sequence

Make the foundational ownership decisions before adding specialized capabilities.

  1. What is an account, which system owns its lifecycle, and how will users authenticate?

    Define account records, creation, recovery, suspension, deletion, authenticators, and sessions without treating account administration as a synonym for login.

    User Management Authentication

  2. What may an authenticated subject do to which resources?

    Model subjects, resources, actions, policies, and enforcement points independently of authentication.

    Authorization

  3. Does the product need organizations, memberships, invitations, active tenant context, and tenant isolation?

    For B2B products, decide the tenant and membership model and whether the application or an identity platform owns it.

    B2B Organizations & Multi-Tenancy

  4. Will customer or workforce identity providers control sign-in or provisioning?

    Evaluate federation and user or group provisioning separately; a deployment may require either or both.

    Single Sign-On User Management

  5. Is proof of wallet-address control part of the product identity model?

    Use Wallet Login only for wallet-native identity and require a signed, domain-bound, nonce-protected ceremony.

    Wallet Login Authentication

579

Decision groups

Each Task owns a distinct user decision rather than a product feature label.

Access control

Keep permission evaluation and enforcement independent from the ceremony that established identity.

Wallet-based identity

Wallet Login is relevant only when signed wallet control is itself an application identity primitive.

7810

Common confusions

These boundaries prevent adjacent Tasks from collapsing into one generic shortlist.

Treating sign-in and permissions as one identity problem.
Authentication establishes identity or authenticator control; Authorization evaluates permitted actions on resources.
Assuming enterprise SSO automatically manages the full user and group lifecycle.
Federation conveys authenticated identity assertions; provisioning manages User and Group resources.
Using generic user management to represent organizations and tenant isolation.
User Management owns accounts; B2B Organizations & Multi-Tenancy owns tenant, membership, and active-context modeling.
Treating proof of wallet-address control as verified personhood.
Wallet Login proves control of an address through a signing ceremony; Identity Verification evaluates real-world identity evidence.
2356

What to defer

Do not add specialized identity systems before the product has the requirement they serve.

No customer or workforce requirement establishes federation, directory integration, or enterprise provisioning.

Enterprise federation adds protocol, tenant-mapping, and operational requirements that ordinary application authentication does not need.

The product has no business tenants, memberships, invitation lifecycle, or tenant-isolation requirement.

A tenant and membership layer should not be introduced for a flat account model.

Wallet-address control is not part of the product identity or transaction model.

Wallet login introduces chain, signing, nonce, replay, and account-linking decisions that conventional identity does not require.

3510

Related starter stacks

See how these decisions appear inside complete application starting points.

Authoritative resources

Standards and primary documentation supporting the Category boundaries.

Sources

Claim-level references used for this decision map.

  1. 1
    Digital Identity Guidelines: SP 800-63-4

    NIST · Accessed Official

  2. 2
  3. 3
    SP 800-63C: Federation and Assertions

    NIST · Accessed Official

  4. 4
    SP 800-63A: Identity Proofing and Enrollment

    NIST · Accessed Official

  5. 5
  6. 6
    Role Based Access Control project and publications

    NIST · Accessed Official

  7. 7
    Organizations overview

    Clerk · Accessed Official

  8. 8
    Configure organization settings

    Clerk · Accessed Official

  9. 9
    Multi-tenant architecture

    Clerk · Accessed Official

  10. 10
    ERC-4361: Sign-In with Ethereum

    Ethereum Improvement Proposals · Accessed Official