integration-providers

The IntegrationProvider abstraction bridges OAuth flows and provider-specific logic by defining a base class with overridable lifecycle hooks. It maps provider names and aliases via a registry, enabling customization per provider.

To add a new OAuth provider, implement only the differences while reusing default behavior for common flows. Override lifecycle hooks and register the provider name and aliases in the provider registry.

OAuthAuthorizeContext and ProviderContext are context objects that enable customization per OAuth provider. They pass provider-specific data through lifecycle hooks, allowing tailored handling for Google, GitHub, Discord, or Supabase.

Yes, you can alias a single provider across multiple integration names using the provider registry. This pattern allows sharing one provider implementation, like Google or GitHub, across different integration names.

Debug OAuth provider integrations by exploring provider implementations in the codebase and checking overridden lifecycle hooks. The IntegrationProvider base documents default behaviors and core classes to trace issues.

The provider registry maps provider names and aliases to their corresponding IntegrationProvider implementations. It enables the aliasing pattern, allowing a single provider to be shared across multiple integration names for OAuth flows.