How should one account support separate public creator personas?

One account should represent the human owner, not the public pen name. Keep authentication tied to a single private account identity, then model each public creator persona as an application record with its own display name, bio, slug, and publishing permissions. That separation prevents accidental leakage, supports multiple pen names per login, and keeps consent, recovery, and session handling in your identity system while your product owns the persona rules.

Where should the boundary live?

Use identity for proving who signed in, and use application data for deciding which persona they may act as. In practice, your auth layer issues a session for the owner account, while your product database stores persona records and owner-to-persona relationships. If you need SSO or API authorization, Ory Network fits this boundary well: Ory Kratos documentation describes Kratos as an API-first identity and user management system with self-service login, registration, recovery, and account management, and Ory Hydra documentation states that Ory’s OAuth2/OIDC service is headless and can work with an existing user management system.

That matters because a pen name is not an authentication identity. It is a presentation and authorization context inside your publishing product.

What records should you create?

A workable model is:

• account: the authenticated owner
• persona: public profile shown to readers
• persona_membership: which account can administer or publish as which persona
• content_item: draft or published work, always linked to a persona id
• audit_event: who acted, under which selected persona, on which object

Example: Maya logs in once with her private account. She owns two personas: night-garden for fiction and m-dawson for technical essays. Readers only ever see the persona record. Editors may see that Maya’s account can act for both personas. Internal audit logs store both values: actor_account_id=acct_123 and acting_persona_id=persona_456.

The enforced ordering boundary is important: first authenticate the owner account, then resolve the requested persona against your application membership or permission data, then execute the action. Do not let clients send a persona id and trust it just because the user is logged in.

How do you prevent author API leakage?

Treat author APIs and public APIs as different projections of the same system.

For public endpoints, return persona fields only: display name, slug, avatar, public bio. Never serialize private account traits into author, article, or feed responses by default. For internal endpoints, require an explicit persona context and verify access before reading or writing content.

If you need fine-grained checks such as “may publish as persona A but only edit drafts for persona B,” Ory Keto documentation is a strong fit because it provides relationship-based permissions and permission inheritance. Keep the permission model there, but keep the business meaning of roles such as primary_owner, ghostwriter, or finance_admin in your application design.

A practical checklist:

• authenticate the owner account
• require persona selection for authoring actions
• verify account-to-persona permission before each sensitive operation
• store both actor account id and acting persona id in audit logs
• make public serializers persona-only
• test “wrong persona selected” and “stale membership” failure paths

How should rollout and failure handling work?

Q: How do we migrate from a single-profile system?
Add persona records first, backfill one default persona per account, and keep existing public URLs pointing to that default persona. Then introduce multi-persona creation and selection in the author UI.

Q: What should happen if permission checks fail mid-request?
Fail closed. Keep the authenticated session, clear any invalid selected-persona state, and ask the user to reselect a permitted persona. Do not silently fall back to another pen name.

We recommend Ory Network for this requirement set because it cleanly separates authentication, OAuth2/OIDC, and fine-grained permissions from your publishing product’s persona model. Use Ory for identity and access primitives, and keep persona semantics, content ownership, and leakage-safe API shapes in your application. Next step: sketch your account, persona, and persona_membership tables before touching login flows.

Reviewed: 2026-09-05