Identity & Access Control

With the built approach, the organization assumes responsibility for the entire Identity and Access Control subsystem, including identity management, authentication, credentials, sessions, token issuance, and authorization.

Unlike Managed and Hybrid, the application does not delegate these responsibilities to an external identity platform. Instead, it implements and operates the required capabilities within its own infrastructure, using established libraries and standards rather than developing security protocols or cryptographic primitives from scratch.

The application exposes its own authentication, identity management, and authorization interfaces. This provides direct control over subsystem behavior, data, security policies, integrations, and operational requirements.

External identity providers may still be supported through federation protocols such as OIDC and SAML. In this case, the organization owns the federation integration and its local identity lifecycle, while the external provider authenticates its own users.

Architecture

flowchart LR
    client["App Client"]
    service["App Service"]
    providers["External Identity Providers"]
    directories["Customer Directories"]

    subgraph iam["App-Owned IAM Subsystem"]
        direction TB
        identity["Identity & Authentication"]
        sessions["Sessions & Token Issuance"]
        authz["Authorization"]
        data[("Identity & Policy Data")]

        identity <--> data
        identity --> sessions
        sessions <--> data
        authz <--> data
    end

    client <-->|"Authentication API / Sessions / Resources"| service

    service <-->|"Identity & Authentication API"| identity
    service <-->|"Session Validation"| sessions
    service <-->|"Permission Checks / Policy Updates"| authz

    identity <-->|"OIDC / SAML"| providers
    directories -->|"SCIM 2.0"| identity

The App Client interacts exclusively with the application's own API for authentication, session management, account operations, and protected resources.

The App Service exposes the client-facing interfaces, coordinates authentication and session operations, and enforces authorization decisions using the IAM subsystem.

The Identity & Authentication Component manages user accounts, credentials, authentication methods, MFA, account recovery, and federation with external identity providers.

The Sessions & Token Issuance Component manages authenticated sessions, their expiration and revocation, and the issuance and validation of tokens where required. Applications using signed access tokens must also manage signing keys and publish verification keys through an appropriate interface, such as JWKS.

The Authorization Component manages roles, permissions, policies, resource relationships, and access decisions. It may be implemented within the application or deployed independently.

The Identity & Policy Data Store maintains the identities, credentials, session records, organizational relationships, and authorization data owned by the subsystem. These responsibilities may be separated across multiple stores when justified by security, consistency, or operational requirements.

External identity providers and customer directories are optional integrations. Supporting federation or automated provisioning does not require delegating ownership of the underlying IAM subsystem.

Core Data Model

A built implementation requires an explicit data model for identities, credentials, sessions, organizations, and authorization.

erDiagram
    USER ||--o{ IDENTITY : links
    USER ||--o{ CREDENTIAL : registers
    USER ||--o{ SESSION : opens
    USER ||--o{ MEMBERSHIP : holds

    ORGANIZATION ||--o{ MEMBERSHIP : contains
    ORGANIZATION ||--o{ ROLE : defines
    ORGANIZATION ||--o{ SSO_CONNECTION : configures

    MEMBERSHIP ||--o{ ROLE_ASSIGNMENT : receives
    ROLE ||--o{ ROLE_ASSIGNMENT : assigned
    ROLE ||--o{ ROLE_PERMISSION : grants
    PERMISSION ||--o{ ROLE_PERMISSION : included

    SESSION ||--o{ REFRESH_TOKEN : rotates

    USER {
        string id PK
        timestamp created_at
    }

    IDENTITY {
        string id PK
        string user_id FK
        string provider
        string provider_subject
    }

    CREDENTIAL {
        string id PK
        string user_id FK
        string type
        string credential_reference
    }

    MEMBERSHIP {
        string id PK
        string user_id FK
        string organization_id FK
        string status
    }

    SESSION {
        string id PK
        string user_id FK
        timestamp expires_at
        timestamp revoked_at
    }

    REFRESH_TOKEN {
        string id PK
        string session_id FK
        string family_id
        timestamp expires_at
        timestamp used_at
    }

The model separates the user, representing the application's internal principal, from the identities and credentials through which that principal authenticates.

A user may authenticate through multiple methods or external identity providers while retaining the same internal identifier, organizational memberships, and permissions.

The model is illustrative rather than exhaustive. Actual implementations may require additional entities for authentication challenges, recovery methods, passkey metadata, MFA enrollment, service accounts, API credentials, policy versions, and audit events.

Refresh tokens and federation connections are optional capabilities, depending on the authentication and session architecture.

Authentication Flow

The application owns the authentication process, from credential verification through session establishment and lifecycle management.

Unlike Hybrid, no external identity broker is responsible for verifying locally managed credentials or issuing the application's primary authentication sessions.

The following sequence illustrates local authentication with an optional additional authentication factor.

sequenceDiagram
    autonumber
    actor C as App Client
    participant A as App Service
    participant I as IAM Subsystem

    C->>A: POST /auth/login
    A->>I: Initiate authentication
    I->>I: Validate credentials and security controls

    alt Additional factor required
        I-->>A: Authentication challenge
        A-->>C: Request additional factor
        C->>A: Submit challenge response
        A->>I: Verify response
        I->>I: Validate additional factor
    end

    alt Authentication successful
        I->>I: Create session and record authentication context
        I-->>A: Identity and session reference
        A-->>C: Set secure session cookie
    else Authentication failed
        I-->>A: Authentication failure
        A-->>C: Generic authentication error
    end

    Note over C,A: Subsequent requests use the application session

The IAM subsystem verifies the supplied authentication factors, applies the relevant security policies, and establishes an authenticated session only after all required checks succeed.

The App Service exposes the authentication interface and delivers the resulting session to the client through a secure, HttpOnly cookie.

Session records must support expiration, revocation, and appropriate invalidation following security-sensitive events. Cookie-based sessions also require CSRF protection and appropriate SameSite configuration.

Authentication Security Requirements

• Credential storage. Passwords must be protected with an appropriate adaptive password-hashing algorithm, such as Argon2id, with securely configured parameters. Passwords and authentication secrets must never be logged or stored in plaintext.
• Authentication methods. Passkeys, MFA, recovery mechanisms, and other authenticators must use maintained implementations of established standards, including WebAuthn where applicable.
• Session protection. Sessions require secure identifiers, expiration policies, revocation mechanisms, and protection against fixation, hijacking, and unauthorized reuse.
• Token security. When signed tokens are issued, the subsystem must manage signing keys securely, validate token claims, rotate keys safely, and define token lifetimes appropriate to their purpose.
• Refresh token protection. When refresh tokens are issued, their storage, binding, rotation or sender constraints, expiration, and replay detection must follow the applicable OAuth security requirements.
• Abuse resistance. Authentication endpoints require appropriate rate limiting, account enumeration resistance, and safeguards against automated credential attacks.
• Account recovery. Recovery and credential-reset mechanisms must provide appropriate assurance without allowing attackers to bypass the primary authentication controls.

Federated authentication follows a different execution path. The subsystem initiates the relevant OIDC or SAML flow, validates the resulting identity assertion, maps the external identity to an internal user, and establishes an application session.

Such federation flows may require browser redirects to an external identity provider, even though the application retains ownership of its authentication interfaces.

Authorization Flow

The application owns both the authorization model and its enforcement.

Unlike Managed, authorization policies are not defined by an external identity platform. Unlike Hybrid, both identity management and authorization operate under the organization's control.

For each protected operation, the App Service validates the authenticated session, resolves the internal principal, and evaluates the requested action against the authorization component.

sequenceDiagram
    autonumber
    actor C as App Client
    participant A as App Service
    participant I as IAM Session Service
    participant E as Authorization Component

    C->>A: PATCH /projects/42 (session cookie)
    A->>I: Validate session
    I-->>A: Authenticated principal and context

    A->>E: check(user:7, edit, project:42)
    E->>E: Evaluate policies and relationships
    E-->>A: Allow or deny

    alt Authorized
        A->>A: Apply requested change
        A-->>C: 200 OK
    else Forbidden
        A-->>C: 403 Forbidden
    end

The authorization component may evaluate organizational memberships, roles, resource ownership, inherited permissions, sharing relationships, contextual attributes, and other application-specific policies.

All protected operations must enforce authorization using trusted identity and resource data. Access is denied by default when no applicable policy grants permission or when a required authorization decision cannot be obtained.

The authorization model may be implemented directly within the application, through a dedicated service, or using a specialized policy or relationship engine.

When authorization data is maintained across multiple stores, implementations must define how policy changes, membership updates, and resource relationships propagate between them.

Depending on the consistency requirements, this may involve transactional updates, event-driven synchronization, versioned policies, reconciliation, or consistency-aware authorization checks.

Revocation semantics must be explicit. Removing access from a user should prevent subsequent protected operations within the guarantees defined by the system. Locally cached permissions, replicated authorization data, and independently validated tokens can introduce delays that must be accounted for.

Limitations

• High development cost. Building an identity subsystem requires implementing and integrating several security-sensitive capabilities, including credential management, authentication, account recovery, sessions, federation, and authorization. Development effort increases significantly as requirements expand.

• Full security responsibility. The organization is responsible for identifying, preventing, and remediating vulnerabilities throughout the subsystem. Errors in authentication, credential handling, token validation, or authorization can compromise the security of the entire application.

• Continuous maintenance. Authentication standards, browser behavior, security recommendations, and external integration requirements evolve. The subsystem requires ongoing updates, dependency reviews, vulnerability remediation, and security testing throughout its lifetime.

• Operational complexity. Identity infrastructure is a critical dependency for the application. Availability, scaling, monitoring, backups, disaster recovery, key management, and incident response must be designed and maintained internally.

• Account recovery and support burden. Credential loss, compromised accounts, MFA resets, identity linking, and account recovery introduce operational workflows that must remain secure while allowing legitimate users to regain access.

• Interoperability requirements. Supporting enterprise SSO, identity federation, provisioning, and external applications requires maintaining compatibility with standards such as OIDC, SAML, SCIM, and WebAuthn. Each supported integration expands the implementation and testing surface.

• Security verification costs. Automated tests alone cannot establish that an IAM implementation is secure. Threat modeling, security reviews, protocol conformance testing, and independent penetration testing require additional expertise and investment.

• Long-term organizational dependency. A custom-built identity subsystem becomes infrastructure the organization must understand and maintain indefinitely. Changes in engineering personnel, security expertise, or business priorities can create substantial maintenance risks.

• Scope expansion. Features commonly provided by established identity platforms become independent engineering responsibilities. Requirements such as enterprise federation, automated provisioning, advanced MFA, and delegated administration can substantially expand the original scope.

Before selecting Built, verify that the critical requirements cannot be satisfied through Managed or Hybrid without unacceptable constraints.