Introduce AuthSessionType to standardize AuthSessionBroker behavior across sessions

[blindzero]

Problem Statement

Providers currently use the Auth/Session broker in different ways (OAuth for Graph/EXO, implicit/no-session patterns for AD, and PSRemoting execution contexts for the Directory Sync / Cloud Sync provider (EntraConnect)).

Without an explicit session classification, it’s harder to:

• validate provider configuration consistently
• manage lifecycle (connect/disconnect, refresh, cleanup)
• implement caching/reuse rules
• emit reliable telemetry/events for diagnostics

We want a consistent mechanism to describe what kind of session the broker is handling.
Target date: 2026-01-31

Proposed Solution

Extend the AuthSessionBroker API and domain model with an explicit AuthSessionType.

Proposed model

• Add AuthSessionType (name is fixed) as a required or strongly-recommended field for session acquisition.
• Typical values (final set can be adjusted):
  • OAuth (Graph, ExchangeOnline)
  • PSRemoting (EntraConnect remote execution)
  • Implicit / None (AD where module/capability exists without explicit session)
  • (optional) LocalElevated if later needed

Behavior

• The broker uses AuthSessionType to:
  • validate required config fields
  • execute type-specific connect/acquire logic
  • determine cleanup rules
  • structure event/log output

Required updates

• Update providers to pass/declare the correct AuthSessionType:
  • IdLE.Provider.EntraID => OAuth
  • IdLE.Provider.ExchangeOnline => OAuth
  • IdLE.Provider.AD => Implicit (or None) unless it has explicit session management
  • IdLE.Provider.DirectorySync.EntraConnect (Directory Sync / Cloud Sync provider) => PSRemoting

Acceptance criteria

• Broker API supports AuthSessionType and validates inputs accordingly.
• All first-party providers compile/run and use the correct AuthSessionType.
• Pester tests cover:
  • validation behavior per AuthSessionType
  • at least one provider per type (OAuth + PSRemoting + Implicit/None)
• Documentation explains how providers should choose AuthSessionType.

Implementation checklist (agent-ready)

• Add AuthSessionType to the relevant domain model(s) / broker request structures
• Add validation rules per type
• Implement type-specific acquisition hooks (even if some are no-ops initially)
• Update providers to specify AuthSessionType
• Add/adjust tests for broker behavior
• Update docs/examples where sessions are configured

Alternatives Considered

• Keep the broker “untyped” and rely on ad-hoc data fields.
  • Rejected: makes validation, lifecycle, reuse and telemetry inconsistent.
• Introduce different broker functions per session kind.
  • Rejected: more API surface and harder to extend; a single typed entry point scales better.

Impact

• Likely a breaking change if AuthSessionType becomes required and existing configs/providers omit it.
  • Since the project is pre-1.0, breaking changes are acceptable but must be documented.
• Provider implementations and tests will need updates.

Additional Context

• This aligns with the architectural principle that the broker handles session lifecycle consistently across providers.
• EntraConnect requires PSRemoting-based execution rather than OAuth, but should still use the same broker pattern.