Ask AI
Skip to main content

Authentication in NoCode-X: Identity Management, SSO, and Safe User Lifecycle (Deactivation vs Deletion)

Authentication is a cornerstone of secure access to resources and applications in NoCode-X. This document explains how identity and authentication work in NoCode-X, how to apply Single Sign-On (SSO) safely, and how to manage the user lifecycle (especially deactivation/suspension vs irreversible deletion) while preserving auditability, attribution, and non-repudiation.

Audience & Scope​

This page is for:

  • Application owners and administrators configuring authentication for NoCode-X
  • Security/compliance teams defining identity governance
  • Developers implementing and operating apps built on NoCode-X

This page covers:

  • Authentication concepts and factors
  • SSO responsibilities and protocols
  • Security principles applied in NoCode-X
  • Safe offboarding patterns (revocation/deassignment vs deletion)
  • Compliance references (GDPR, ISO 27001:2022, NIST, Cyber Fundamentals Essentials)

Definitions (NoCode-X context)​

  • System identity: An identity represented as a UUID (Universally Unique Identifier) inside NoCode-X.

  • Email address: A user-facing reference linked to the UUID. It is used for login/user recognition, but it is not the system identity.

  • Developer vs User (runtime user)
    In NoCode-X it’s important to distinguish who builds applications from who uses the applications at runtime:

    • Developer (builder/creator)

      • A Developer is a licensed NoCode-X user who builds and maintains applications (design, logic, data, APIs, security configuration).
      • Developers typically hold privileged capabilities, depending on their assigned rights, such as access to configuration and platform-level functions (e.g., identity and security configuration, and—in setups where applicable—elements tied to the identity provider / authentication configuration).
      • Developers must follow the same security fundamentals (least privilege, need-to-know, auditability) but are treated as higher-risk accounts because they can change application behavior and platform configuration.

    • User (application/runtime user)

      • A User is an end-user of an application that was built on NoCode-X. They are intended to access runtime applications, not platform administration or infra/devops-level controls.
      • Runtime users do not require additional NoCode-X developer licenses. Whether your application has 1 user or 1,000,000 users, the user base cost is included in the runtime and does not add per-user licensing.
      • Runtime users typically have no access to developer/admin configuration surfaces (e.g., they do not manage identity provider settings, platform security controls, or build-time resources).

    • Why this distinction matters (security + governance)

      • Developers are privileged identities and should be protected accordingly (e.g., MFA, stronger assurance, stricter access reviews, break-the-glass patterns).
      • Runtime users are workload identities that should be governed through app-level authorization and lifecycle controls (assignment, deassignment, suspension), without needing to delete identities for cost reasons.

  • Deassign / Revoke access: Remove a user’s permissions to projects/apps without deleting their UUID identity.

  • Delete user (hard delete): Remove the user identity record entirely. This permanently removes the UUID.

Core Concepts​

1) Authentication (proving who a user is)​

Authentication verifies the identity of users accessing NoCode-X. NoCode-X supports robust authentication approaches using standard factors:

  • Knowledge factor: something the user knows (e.g., password)
  • Property factor: something the user has (e.g., TOTP, YubiKey/security key)
  • Inherence factor: something the user is (e.g., biometrics)

GDPR note: why inherence factors (biometrics) are disadvised​

NoCode-X disadvises inherence factors (biometrics) in centralized authentication/identity systems due to GDPR compliance concerns (see the dedicated section below). Recommended practice is strong authentication using knowledge + property factors, especially for privileged users.

2) Identity in NoCode-X (UUID + email)​

A user exists in NoCode-X as:

  • a UUID (the system identity; unique and not re-creatable), linked to
  • an email address (a reference for user experience and login association)

Security implication:

  • A UUID cannot be recreated on the system.
  • If a user is hard deleted, the UUID is gone.
  • You may recreate a user with the same email, but the system will assign a new UUID.
  • From a system and object-level security perspective, that recreated user is a different user identity.

This UUID-based identity model supports:

  • Attribution: trace actions to a specific identity
  • Non-repudiation: reduce the ability to deny actions tied to an identity
  • Audit integrity: maintain trustworthy logs over time

3) Single Sign-On (SSO)​

SSO allows users to authenticate once with an external Identity Provider (IdP) and access NoCode-X without separate NoCode-X credentials.

NoCode-X supports:

  • OpenID Connect 1.0 (preferred for strict, modern standards)
  • OAuth 2.0

When SSO is enabled:

  • The IdP becomes responsible for authentication strength and credential lifecycle.
  • NoCode-X consumes the authentication outcome and enforces authorization inside the platform (roles, groups, assignments).

Principles (Security by Design in NoCode-X)​

1) Security by Design (levels of assurance)​

Authentication mechanisms must match the risk level of the account:

  • Level 2: standard users
  • Level 3: sensitive accounts (e.g., managers, administrators, privileged developers)

Recommended practice:

  • Enforce MFA for privileged users.
  • Prefer property factors (TOTP or hardware keys) for strong assurance.

2) Responsibility for authentication (who owns what)​

NoCode-X supports both self-managed authentication and SSO. Responsibilities differ depending on the model:

A) Self-Managed Authentication (embedded authentication)​

When NoCode-X embedded authentication is used, the application owner is responsible for:

  • authentication strength
  • MFA enforcement decisions
  • provisioning and offboarding
  • lifecycle governance of user access

B) SSO with External IdP​

When SSO is enabled, the external IdP is responsible for:

  • authentication provisioning
  • assurance of user identity and credentials (including MFA)
  • lifecycle management of user accounts (disable, lock, revoke, monitor)

NoCode-X enforces:

  • project/app authorization
  • least privilege access in NoCode-X permissions and rights

3) Break-the-Glass Accounts (emergency access)​

For resilience and operational continuity:

  • Use special “break-the-glass” accounts protected by additional property factors (e.g., YubiKey).
  • Ensure usage is logged and monitored.
  • Restrict availability and use only for emergencies.

Why Inherence Factor (Biometrics) is Disadvised (GDPR + Security)​

The inherence factor (biometrics) can be strong for local device unlock, but its use in centralized systems for identifying individuals is disadvised due to GDPR compliance concerns:

  1. No legal basis for centralized biometric processing

    • Under GDPR, there is typically no legal ground to process biometrics in a central repository for identifying natural persons.
    • Article 9 GDPR classifies biometric data as special category data requiring explicit consent or a specific legal basis. Many organizations cannot meet these requirements for centralized biometric identification.

  2. Risk of non-conformity by design

    • Central biometric identification may lead to by design non-conformity for the data controller.

  3. Security risks

    • Biometric repositories are high-value targets.
    • If compromised, biometrics cannot be changed like passwords or tokens, leading to irreversible harm.

  4. Recommended alternatives

    • Prefer knowledge factors (passwords) combined with property factors (TOTP, YubiKey/security keys) for strong authentication.

Why Use Single Sign-On (SSO) with NoCode-X?​

Advantages​

  1. Improved user experience

    • Users log in once and access multiple applications seamlessly.

  2. Centralized authentication

    • Simplifies identity management and reduces password fatigue.

  3. Enhanced security

    • Consolidates authentication policy enforcement in the IdP (MFA, conditional access).

  4. Scalability

    • Integrates with enterprise identity and access management practices.

Considerations​

  • The IdP entity is responsible for authentication strength and credential lifecycle.
  • The IdP should have documented processes for:
    • monitoring
    • incident response
    • periodic access review

User Lifecycle in NoCode-X: Deactivation/Suspension vs Deletion​

Q: Is there a safe user deactivation/suspension flow separate from irreversible user deletion?​

Yes. NoCode-X supports revoking access without deleting the user identity (UUID). This is the preferred operational security pattern for most offboarding and role-change scenarios.

Security rationale: why hard deletion is different​

In NoCode-X:

  • user identity = UUID
  • user reference = email

If you hard delete a user:

  • the UUID is removed permanently
  • you can recreate a user with the same email, but it receives a new UUID
  • from system/object-level security, this is a different identity
  • this impacts controls tied to identity continuity, including:
    • attribution
    • non-repudiation
    • audit interpretation

To safely suspend/deactivate a user:

  1. Deassign the user from projects

    • Remove access to all relevant workspaces/projects.

  2. Deassign the user from apps

    • Remove roles/rights in applications they should no longer access.

  3. Disable authentication where applicable

    • With SSO: disable/suspend the user in the IdP (recommended).
    • With embedded auth: disable the user’s ability to authenticate and revoke permissions.

Outcome:

  • Access is revoked (prevents impersonation and unauthorized access).
  • The identity object (UUID) remains for audit integrity.
  • Historical actions remain attributable to the same identity.

Cost/licensing note​

A deassigned user (no project/app access) can remain in the system as a “lingering object” and does not cost you anything as described here. This enables secure offboarding without creating licensing pressure to hard delete.

Developer vs Business user: governance and cost nuance​

Both developers and business users:

  • must follow need-to-know access principles
  • should be governed using least privilege
  • benefit from UUID-based non-recreatable identities for audit and attribution

Business users:

  • typically do not impact licensing cost in the same way (as stated here), so you can keep identities for audit continuity even if they are inactive.
  • still require common-sense housekeeping (access reviews, cleanup of unused access paths).

User self-removal (right to be forgotten)​

A user can remove themselves from the system, consistent with their right to be forgotten. When deletion is requested/required for privacy reasons, hard deletion becomes appropriate.

Important nuance:

  • If later re-added with the same email, the system will assign a new UUID, meaning a new identity from the system’s viewpoint.

Re-adding a user​

  • If the user was deassigned (not deleted):

    • you can reassign them to projects/apps
    • identity continuity remains (same UUID)

  • If the user was deleted:

    • you can recreate the user using the same email
    • the system will generate a new UUID
    • this is a new identity with different object-level security implications

Compliance & Security Standards Mapping​

ISO 27001:2022​

  • Clause 8.1 (Operational Planning and Control)
    Ensures authentication processes are planned, implemented, and monitored.
  • Annex A.9.4.2 (Secure Log-On Procedures)
    Supports secure authentication mechanisms, including MFA and SSO.
  • Annex A.9.2.3 (Management of Privileged Access Rights)
    Enforces strong authentication for sensitive accounts.

NIST-53 CSF​

  • PR.AC-1 (Identity Management)
    Ensures identities and credentials are issued, managed, and verified.
  • PR.AC-4 (Access Permissions and Authorizations)
    Incorporates least privilege and separation of duties.
  • PR.AC-7 (Identity Proofing)
    Ensures identities are proofed and bound to credentials.

Cyber Fundamentals Essentials​

  • PR.AC-1 (Identity and Credential Management)
    Enforces strong authentication policies, including MFA.
  • PR.AC-4 (Access Permissions)
    Limits access to only what is necessary for roles.
  • PR.AC-6 (Authentication Assurance)
    Ensures authentication mechanisms are robust and monitored.

Summary (Operational Guidance)​

  • Prefer SSO (OpenID Connect 1.0) where possible to centralize authentication assurance and lifecycle management.
  • Enforce MFA for privileged roles; prefer property factors (TOTP/security keys).
  • Avoid centralized biometric authentication due to GDPR and breach impact risks.
  • For offboarding or temporary suspension, revoke access (deassign from projects/apps) instead of deleting.
  • Use hard deletion only when required (e.g., privacy “right to be forgotten”), knowing that recreating the same email produces a new UUID and therefore a new system identity.