Identity & Access Control

With the managed approach, the application delegates identity management, authentication, and authorization management to an external identity broker. The broker manages user directories, authentication methods, identity provider integrations, organizations, roles, and permissions.

The application does not store user passwords or authentication credentials. It redirects users to the broker for authentication, establishes its own application sessions, and enforces access decisions using trusted authorization data supplied by the broker.

Typical platforms include Auth0, Clerk, WorkOS, Amazon Cognito, Microsoft Entra External ID, Firebase Authentication, and Supabase Auth. Their capabilities differ, particularly around organization management and authorization.

Architecture

flowchart LR
    client["App Client"]
    service["App Service"]
    broker["Managed Identity Broker"]
    providers["External Identity Providers"]

    client <-->|"Pages / API requests / session cookie"| service
    client <-->|"Hosted sign-in / browser redirects"| broker

    service -->|"Token exchange / JWKS / Management API"| broker
    broker -->|"Tokens / keys / identity data / webhooks"| service

    broker <-->|"OIDC / SAML"| providers

The App Client interacts with the broker through browser-based authentication flows and communicates with the App Service using a secure session cookie.

The App Service validates application sessions, enforces authorization, and integrates with the broker through standardized protocols and management APIs. It does not need to contact the broker on every request.

The Identity Broker remains responsible for managing identities, authentication, roles, permissions, and external identity provider integrations.

The application may maintain thin shadow records containing broker identifiers and application-specific foreign keys. Authorization claims or grants may also be cached locally, provided their freshness and invalidation requirements are respected.

Authentication Flow

sequenceDiagram
    autonumber
    actor C as App Client
    participant A as App Service
    participant P as Identity Broker

    C->>A: Open protected page
    A->>A: Generate state, nonce, and PKCE values
    A-->>C: Redirect to authorization endpoint
    C->>P: Authorization request (state, nonce, code challenge)
    P-->>C: Hosted sign-in
    C->>P: Complete authentication (password, passkey, SSO, MFA)
    P-->>C: Redirect to callback (code, state)
    C->>A: Deliver authorization code and state

    A->>A: Validate state
    A->>P: Exchange code (PKCE verifier)
    P-->>A: ID token, access token, optional refresh token
    A->>A: Validate ID token signature and claims
    A->>A: Resolve user and create application session
    A-->>C: Set secure session cookie

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

The App Service validates the ID token's signature and relevant claims, including issuer, audience, expiration, and nonce, before establishing the session.

The application session is represented by a cookie configured with appropriate security attributes, including HttpOnly, Secure, and SameSite. The server validates the session on subsequent requests.

Access and refresh tokens, when required for downstream integrations, are retained securely on the server rather than exposed to browser JavaScript.

Authorization Flow

The broker manages roles, permissions, and their assignments. The App Service enforces these permissions when handling protected operations.

Authorization data can be obtained from validated token claims, server-side session data, synchronized grants, or the broker's APIs, depending on the provider and the application's consistency requirements.

sequenceDiagram
    autonumber
    actor C as App Client
    participant A as App Service
    participant P as Identity Broker

    C->>A: Request protected resource (session cookie)
    A->>A: Validate session and resolve identity

    alt Authorization data available locally
        A->>A: Read trusted claims or cached grants
    else Current permissions required
        A->>P: Retrieve authorization grants
        P-->>A: Roles and permissions
    end

    A->>A: Evaluate permission and resource scope

    alt Authorized
        A-->>C: Return requested resource
    else Forbidden
        A-->>C: 403 Forbidden
    end

Authorization must be enforced on every protected operation. The application must verify both the required permission and its applicability to the requested organization or resource.

Permissions must be evaluated using trusted server-side data, never solely from client-supplied roles or claims.

Permission changes and revocation require particular attention. Cached authorization data may remain valid after permissions have been modified or revoked. Applications requiring immediate revocation must use sufficiently fresh authorization data, explicit cache invalidation, or an appropriate online authorization mechanism.

Limitations

• Vendor dependency. Identity records, authentication methods, and integrations depend on the selected platform. Migrating to another provider may require substantial integration changes, data migration, and user re-enrollment, particularly when credentials or MFA enrollments cannot be exported.

• Authorization constraints. The platform's authorization model may not support complex resource relationships, inherited permissions, or context-dependent policies. Requirements beyond its capabilities may justify adopting the Hybrid scope.

• Limited customization. Authentication flows, session behavior, identity schemas, and security policies are constrained by the platform's supported configuration and extension mechanisms.

• Pricing at scale. Usage-based pricing, enterprise connections, and feature-specific charges may become significant as the user base and integration requirements grow.

• External availability dependencies. Platform outages may prevent new sign-ins, token refreshes, management operations, or online authorization checks. Existing application sessions may continue functioning if their validation and required authorization data remain available locally.

• Permission propagation delays. Changes to roles, memberships, or permissions may not immediately affect existing sessions or cached grants. Applications requiring immediate revocation need additional invalidation or online verification mechanisms.

• Management API constraints. Rate limits, network latency, and availability dependencies can make management APIs unsuitable for request-critical operations. Local claims, synchronized records, or caching can reduce these dependencies but introduce consistency considerations.