auth.provider API
    Preparing search index...

    Interface ContributesMap<Deps>

    Declaration-merged map of contribution kinds.

    Per A2-α §4.1 the v0.5.0 baseline declares 7 kinds. A5 (Phase 7) adds federationRedirectPolicies via declare module augmentation in the session package; consumer plugins may add custom kinds the same way.

    Per A2-α §4.5 collision policy:

    • Name-keyed (grants, federations, tokenExchangeValidators, mfaFactors): throw on duplicate at boot (enforced in Phase 4 / A2-β).
    • List-shaped (auditHooks, routes, grantPolicyHooks, grantMiddleware): allow duplicates; routes additionally throw on duplicate id / undecorated-mountPath collisions.

    Per A2-α §4.2 every contribution factory shares the declaring module's top-level requires / optional typed Deps object — there is no per-contribution dep declaration.

    interface ContributesMap<Deps = ProviderDeps<never, never>> {
        auditHooks?: readonly AuditHookFactory<Deps>[];
        discoveryMetadata?: readonly OidcDiscoveryContributionFactory<Deps>[];
        federations?: { readonly [name: string]: FederationFactory<Deps> };
        grantMiddleware?: readonly GrantMiddlewareFactory<Deps>[];
        grantPolicyHooks?: readonly GrantPolicyHookFactory<Deps>[];
        grants?: { readonly [grantType: string]: GrantFactory<Deps> };
        mfaFactors?: { readonly [kind: string]: MfaFactorFactory<Deps> };
        routes?: readonly RouteContributionEntry<Deps>[];
        tokenBindingMechanisms?: readonly TokenBindingMechanismFactory<Deps>[];
        tokenExchangeValidators?: {
            readonly [tokenType: string]: ExchangeTokenValidatorFactory<Deps>;
        };
    }

    Type Parameters

    Index

    Properties

    auditHooks? discoveryMetadata? federations? grantMiddleware? grantPolicyHooks? grants? mfaFactors? routes? tokenBindingMechanisms? tokenExchangeValidators?

    Properties

    auditHooks?: readonly AuditHookFactory<Deps>[]
    discoveryMetadata?: readonly OidcDiscoveryContributionFactory<Deps>[]

    OIDC discovery metadata contributions. List-shaped — each endpoint-owning module contributes the endpoints + literal fields it wants advertised, and core's assembleApp aggregates them into the single /.well-known/openid-configuration document (mounted only when an issuer is configured). The aggregator owns issuer and id_token_signing_alg_values_supported; contributions supply issuer- relative endpoints (e.g. authorization_endpoint, jwks_uri) and literal metadata (capability arrays, logout flags). See core/src/discovery/buildDocument.mts for the merge + validation rules.

    federations?: { readonly [name: string]: FederationFactory<Deps> }
    grantMiddleware?: readonly GrantMiddlewareFactory<Deps>[]

    Express middleware mounted on the OAuth token endpoint (/oauth/token with the bundled oauthModule) BEFORE grant dispatch (Wave 2 Token-binding Cluster spec §4.7 — added in Phase 1 retro for the tokenBindingMw composition surface).

    Use cases: token-binding middleware (DPoP, mTLS), custom rate- limiters, request body pre-processing. Factories that return null are skipped at composition time (typical when a mechanism is disabled by config).

    List-shaped — multiple modules may contribute. Composition order is module-registration order. Within one middleware factory the DispatchPolicy configured on tokenBindingMw decides which mechanism wins.

    Cross-contribution composition is plain Express middleware ordering — tokenBindingMw unconditionally assigns req.tokenBinding when it resolves a binding (no guard against an already-populated field), so a later grantMiddleware contribution that resolves a binding will overwrite the earlier one. Modules that need deterministic dispatch across competing mechanisms should compose them into a single tokenBindingMw call (where DispatchPolicy arbitrates) rather than register each mechanism as its own grantMiddleware factory.

    grantPolicyHooks?: readonly GrantPolicyHookFactory<Deps>[]
    grants?: { readonly [grantType: string]: GrantFactory<Deps> }
    mfaFactors?: { readonly [kind: string]: MfaFactorFactory<Deps> }
    routes?: readonly RouteContributionEntry<Deps>[]
    tokenBindingMechanisms?: readonly TokenBindingMechanismFactory<Deps>[]

    Mechanism contributions composed by core into a single tokenBindingMw instance mounted on the OAuth token endpoint (/oauth/token with the bundled oauthModule) BEFORE grant dispatch.

    Use this — NOT grantMiddleware — when a module ships a token-binding mechanism (DPoP, mTLS, future). Core's assembleApp collects all contributions, filters nulls, and composes one tokenBindingMw with the configured DispatchPolicy arbitrating cross-module:

    • intent-explicit (default): explicit-intent mechanisms (DPoP) win over ambient mechanisms (mTLS) on a single request. ≥2 explicit- intent mechanisms succeeding → 400 invalid_request.
    • strict-mutual-exclusion: any 2+ mechanisms succeeding → 400 invalid_request.

    The dispatch-policy comes from config.oauth.tokenBinding.dispatch-policy (declared by core's bundled config schema).

    List-shaped — multiple modules may contribute. Within a single module a factory typically returns one mechanism (or null when disabled by config), but the list is allowed to contain multiple factories to support a single module shipping multiple mechanisms.

    See ADR packages/core/docs/adr/2026-05-20-token-binding-first-class-abstraction.md for the cross-mechanism design rationale.

    tokenExchangeValidators?: {
        readonly [tokenType: string]: ExchangeTokenValidatorFactory<Deps>;
    }

    Settings

    Member Visibility

    On This Page

    Properties