Shared Login or Separate Accounts? Choosing an Identity Model for Self-Hosted Applications

Login architecture becomes an operational decision as your stack grows

One self-hosted application can usually be managed with local user accounts. When a team operates several applications, however, login design affects more than user convenience. It affects who creates accounts, how quickly access is removed, where administrators retain recovery access, and what happens if a shared login service is unavailable.

A shared identity provider for self-hosted applications can reduce repeated account-management work. It can also become a critical dependency: if the identity service, its administration process, or its recovery process fails, users may be unable to reach several services at once. The right choice is therefore not automatically “centralise everything.” It is the model your team can operate and recover safely.

Airbip manages cloud infrastructure around deployed Docker application workloads, including routing and TLS certificate automation, DNS checks, service lifecycle management and configurable backups. Those infrastructure services do not choose an application's identity source, permission model, account recovery process or access governance. Those remain customer decisions that should be made application by application.

• Treat identity architecture as an operational design decision, not just a login-screen preference.
• Assess the likely impact of an identity-service outage before making it the entry point to every application.
• Assign named owners for user lifecycle activity, privileged access and recovery procedures.
• Keep the identity decision separate from application backup, data retention, session management and application authorization decisions.

Start with the distinction: authentication, authorization and roles

Authentication answers, “Can this person prove control of the authenticator associated with this identity?” NIST describes successful authentication as allowing a verifier to assert an identifier, and optionally attributes, to the service being accessed.

Authorization is a separate decision: “What may this authenticated person do here?” An application may use information received during authentication when making that decision, but it still needs its own logic for access. Application-level roles then express the permissions available within that application, such as an administrator role, an editor role or a read-only role.

This distinction prevents a common design error. A central login can establish who someone is across multiple applications, but it does not inherently make permissions consistent across them. The same person may appropriately be an administrator in one system and have limited access in another. Each application’s current official documentation should be the source of truth for its roles, group behaviour and any identity integration it supports.

• Authentication: verifies the claimant’s control of an authenticator.
• Authorization: determines access to a service or resource.
• Roles and groups: represent application-specific permissions and responsibilities.
• Sessions: govern how an authenticated browser or client remains signed in; they need their own controls and review.

The three workable identity models

Separate local accounts mean each application maintains its own users and authentication methods. This model has more repetitive administration, but an outage or configuration problem in one application does not automatically prevent login to the rest of the stack.

A shared identity-provider model uses federation where supported: the identity provider authenticates the person and sends an assertion to the relying application. The application verifies the assertion, creates an authenticated session and grants access to its functions. Federation can reduce the need for separate authenticators at multiple applications and can centralise parts of account management.

A hybrid model combines the two. For example, a team may use a shared identity provider for applications that support it and retain carefully controlled local accounts where an application requires them or where emergency administrative access is needed. Hybrid is often a deliberate operating model, not an incomplete migration.

• Local accounts: fewer shared dependencies; more account administration in each application.
• Shared identity provider: one primary authentication process; greater concentration of operational risk.
• Hybrid: accommodates different application capabilities while preserving a documented fallback path.
• Do not assume a product supports federation, automated provisioning, granular group mapping or a particular protocol. Confirm its current primary documentation and your deployment configuration.

When separate accounts are the safer choice

Separate accounts are often proportionate for a small, stable team with a limited number of applications, infrequent joiners and leavers, and no one responsible for operating a dedicated identity service. In this situation, a central identity platform may add more configuration, recovery and monitoring work than it removes.

This choice is only safe when the repeated work is genuinely manageable. Local accounts need a clear joiner, mover and leaver process. If access removal depends on someone remembering every application, the model can fail silently as the stack expands.

Use least privilege in every application: grant only the access required for a defined responsibility, keep administrative accounts limited, and record who owns each role. A small environment can use a simple register and scheduled review rather than a complex identity platform, provided the register is kept current.

• Choose local accounts when user numbers are small and account changes are uncommon.
• Choose local accounts when your team lacks the capacity to administer, secure and recover a shared identity service.
• Use unique account records rather than a shared team login so actions can be attributed and access can be removed for one person.
• Keep an inventory of every application, account owner, privileged account, recovery contact and review date.
• Ensure each critical administrator has a documented recovery method and avoid designing recovery around a single individual.

When shared login is justified

Centralised authentication becomes more compelling when onboarding and offboarding happen frequently, when the number of applications makes repeated administration unreliable, or when the organization already has mature identity controls and clear administrative ownership. The benefit is not simply fewer passwords; it is a more repeatable way to establish and remove access to supported services.

Federation does not remove the relying application from the access model. NIST notes that a federated relying-party account must be provisioned before an authenticated session can be created, and that the application can disable or terminate its local account independently of the identity provider. Plan for both sides: the identity record and the application account or authorization record.

Centralise only where the gain is real. An application that has no supported integration, needs a local administrator, or has a different lifecycle may remain local. Forcing every service through one access path can create fragile workarounds and obscure accountability.

• Prioritise shared login where account churn makes manual local administration error-prone.
• Verify the exact integration option, role behaviour and account-provisioning method in official documentation before committing to a design.
• Define who can administer the identity provider, approve access and change application role assignments.
• Document how access is revoked at both the identity provider and each relying application.
• Test the effect of identity-provider unavailability on normal users and administrators.

Questions to answer before centralising authentication

Start with compatibility, but do not stop there. For every application, identify the supported authentication and federation options from the current primary documentation, the required configuration, the account-provisioning behaviour and the way local exceptions work. Product capabilities can differ by product, edition, version and deployment configuration.

Next, design administration and recovery. Account recovery is distinct from routine authentication. NIST identifies recovery approaches including saved or issued recovery codes, recovery contacts, repeated identity proofing and application-specific methods grounded in documented risk analysis. NIST also recommends encouraging users to maintain at least two separate means of authentication to reduce recovery events.

Finally, decide what happens if the normal route is unavailable. A break-glass account is an emergency administrative access path, not an everyday shortcut around governance. It should have a named owner, restricted use, protected recovery material, a documented test procedure and a review after every use.

• Which authentication or federation options does each application currently support?
• Who owns the identity-provider tenant or service, its privileged accounts and its configuration changes?
• Which application accounts still need to exist locally, and why?
• How are new users created, role changes approved and departed users removed?
• What is the break-glass path if the identity provider, an administrator account or an authenticator is unavailable?
• Who holds recovery contacts or recovery material, and how is that access protected and tested?
• How are sessions ended or reauthenticated when risk or role changes require it?
• What evidence will show that access and permissions were reviewed?

Centralised authentication does not create consistent permissions

A shared identity provider can give a person one authentication experience across supported applications. It does not automatically define what that person may do after login. Authorization and access determination remain application decisions, and different applications may interpret roles, groups and attributes differently.

Avoid assigning broad administrative rights merely because a user has successfully signed in through the central service. Instead, define an access matrix for each application: job responsibility, application role, approver, account owner and review frequency. Where group or attribute mapping is available, verify its actual behaviour in the product’s current documentation and test it with non-production accounts where possible.

External authentication layers can also have a narrow role. For example, Traefik ForwardAuth delegates authentication to an external service and permits access when that service returns a 2XX response. That describes an authentication gate; it does not itself establish an application’s internal roles, data permissions or lifecycle controls.

• Maintain application-specific role definitions even when authentication is shared.
• Require explicit approval for privileged roles.
• Review group-to-role mappings whenever either the identity configuration or application configuration changes.
• Do not treat a reverse-proxy authentication gate as a complete authorization system.
• Keep session controls and data-access rules in scope as separate application security concerns.

Operate the model with evidence, reviews and documented ownership

Whichever model you choose, maintain an application-by-application identity register. Record the identity source, application owner, privileged accounts, local-account exceptions, recovery contacts, normal provisioning method, deprovisioning method, and the evidence from the last permission review. This gives a growing team an auditable operational record without assuming unsupported automation.

Build reviews around joiners, movers and leavers. A joiner needs only the approved access required to begin work. A mover needs old rights reassessed as responsibilities change, not simply new rights added. A leaver needs prompt removal or disabling of access through every relevant route, including local exceptions and privileged accounts. Set a cadence based on change volume and risk, then retain evidence that the review occurred and exceptions were resolved.

NIST’s Cybersecurity Framework 2.0 highlights governance through roles, responsibilities, authorities, policy and oversight. Apply that principle practically: someone should own the identity service, someone should own each application’s authorization model, and escalation paths should be known before a lockout or departure occurs.

Managed Docker application hosting can reduce infrastructure administration around deployed services. It is not a substitute for identity engineering or enterprise identity governance. If directory integration, regulatory obligations, high availability or formal identity assurance requirements exceed your team’s capacity, use a specialised identity service or enterprise hosting arrangement rather than treating a general managed application platform as a complete identity-management solution.

• Create and maintain an identity register for every application.
• Review access after role changes, not only during periodic audits.
• Review privileged accounts more closely than ordinary accounts.
• Document local-account exceptions and remove them when they are no longer justified.
• Test recovery and break-glass procedures at a planned cadence; record outcomes and remedial actions.
• Use official application and identity-provider documentation as the basis for configuration and control decisions.
• Reassess the model when application count, staff turnover, sensitivity of data or operational requirements change.