Problem
The Asgardeo SDK is currently a closed system. It ships with fixed behavior for rendering, flow handling, theming, and authentication logic. Consumers who need to adapt the SDK to their product — different design systems, custom flow steps, non-standard component types, bespoke UI patterns — have no supported way to do so. The only escape hatch today is forking or wrapping SDK internals, which breaks on upgrades and couples consumers to implementation details.
As adoption grows, this rigidity becomes a ceiling. Products built on the SDK inevitably hit cases the SDK didn't anticipate, and without extension points, those teams are blocked.
Proposed Solution
Introduce a first-class, documented extension model that allows consumers to plug into the SDK at well-defined boundaries — without forking, without bypassing internals, and without waiting for the SDK team to implement every edge case.
Areas where extensions are needed
- UI rendering — Replace or supplement how specific component types are rendered (e.g. swap the built-in password field for a custom design system component, or handle a server-emitted component type the SDK doesn't know about)
- Flow lifecycle hooks — React to flow events (step transitions, errors, completions) with custom side effects or analytics
- Authentication behavior — Override or augment how specific authenticator types are handled
- Field validation — Plug in custom validation logic per field or component type
- Theming and styling — Go beyond CSS variable overrides to control rendering structure
A structured extensions API on the SDK provider that serves as the canonical entry point for all consumer customizations, with each area having a clear, typed, and stable contract.
Alternatives
N/A
Please select the package issue is related to
other
Version
N/A
Reporter Checklist
Problem
The Asgardeo SDK is currently a closed system. It ships with fixed behavior for rendering, flow handling, theming, and authentication logic. Consumers who need to adapt the SDK to their product — different design systems, custom flow steps, non-standard component types, bespoke UI patterns — have no supported way to do so. The only escape hatch today is forking or wrapping SDK internals, which breaks on upgrades and couples consumers to implementation details.
As adoption grows, this rigidity becomes a ceiling. Products built on the SDK inevitably hit cases the SDK didn't anticipate, and without extension points, those teams are blocked.
Proposed Solution
Introduce a first-class, documented extension model that allows consumers to plug into the SDK at well-defined boundaries — without forking, without bypassing internals, and without waiting for the SDK team to implement every edge case.
Areas where extensions are needed
A structured
extensionsAPI on the SDK provider that serves as the canonical entry point for all consumer customizations, with each area having a clear, typed, and stable contract.Alternatives
N/A
Please select the package issue is related to
other
Version
N/A
Reporter Checklist