Skip to main content
This guide covers how to add new OAuth integrations to OpnForm. The system uses a modern, service-oriented architecture with intent-based OAuth flows to handle different authentication scenarios including user authentication, account integrations, and widget-based providers.

Configuration Guide

Before implementing a new integration, you may want to review the OAuth configuration guide to understand how to set up the existing Google, Stripe, and Telegram integrations.

System Architecture Overview

OpnForm’s OAuth system is built around several key architectural patterns:
  • Intent-based Flows: Different OAuth scopes and handling based on auth vs integration intents
  • Orchestrator Pattern: Central OAuthFlowOrchestrator coordinates all OAuth flows
  • Service-Oriented Architecture: Specialized services handle context, user data, invites, and provider management
  • State-based Context Management: Secure state tokens replace session-based context storage
  • Driver Pattern: Abstracted OAuth provider implementations with support for redirect and widget flows
  • Email Restrictions: Capability-based email restrictions for workspace invitations
  • Message-based Communication: Cross-window communication for OAuth callbacks

Core Components

1. OAuthController (api/app/Http/Controllers/Auth/OAuthController.php)

The simplified controller that delegates all OAuth logic to the orchestrator:
Key Features:
  • Simplified Architecture: All logic delegated to OAuthFlowOrchestrator
  • Request Validation: Uses OAuthRedirectRequest for structured validation
  • Consistent Responses: Standardized JSON response format

2. OAuthFlowOrchestrator (api/app/Service/OAuth/OAuthFlowOrchestrator.php)

The main orchestrator service that coordinates all OAuth flows:
Key Features:
  • Centralized Coordination: Single entry point for all OAuth flows
  • State Management: Handles OAuth state tokens for security
  • Invite Integration: Supports workspace invitations with email restrictions
  • Intent-based Routing: Routes to appropriate flow based on auth vs integration intent

3. OAuthContextService (api/app/Service/OAuth/OAuthContextService.php)

Service that manages OAuth context using secure state tokens:
Key Features:
  • State Token Security: Uses cryptographically secure state tokens instead of session storage
  • Context Isolation: Each OAuth flow has isolated context
  • Automatic Cleanup: Context automatically expires and clears after use

4. OAuthUserDataService (api/app/Service/OAuth/OAuthUserDataService.php)

Service that extracts and normalizes user data from OAuth providers:
Key Features:
  • Data Normalization: Standardizes user data across different OAuth providers
  • Widget Support: Handles both redirect and widget-based authentication flows
  • Error Handling: Validates and verifies OAuth provider responses

5. OAuthInviteService (api/app/Service/OAuth/OAuthInviteService.php)

Service that handles workspace invitations and email restrictions:
Key Features:
  • Invite Validation: Validates workspace invitation tokens
  • Email Restrictions: Enforces email restrictions for OAuth providers that support it
  • Capability-based: Uses interfaces to determine if driver supports email restrictions

6. OAuthUserService (api/app/Service/OAuth/OAuthUserService.php)

Service that handles user-related OAuth operations:
Key Features:
  • User Management: Creates new users or finds existing ones
  • Workspace Integration: Uses WorkspaceInviteService for workspace assignment
  • UTM Tracking: Preserves UTM data for analytics

7. OAuthProviderService (api/app/Service/OAuth/OAuthProviderService.php)

Service that handles OAuth provider record management:
Key Features:
  • Provider Records: Manages OAuth provider connections in database
  • Token Management: Stores and updates OAuth access/refresh tokens
  • Scope Tracking: Records granted OAuth scopes

8. WorkspaceInviteService (api/app/Service/WorkspaceInviteService.php)

Service extracted from RegisterController that handles workspace creation and invitation acceptance:
Key Features:
  • Workspace Creation: Creates new workspaces for users without invitations
  • Invite Processing: Handles workspace invitation acceptance with atomic updates
  • Role Assignment: Assigns appropriate roles based on invitation or default admin role

9. OAuth Drivers

Each provider implements the OAuthDriver interface with updated methods:
For widget-based providers, implement WidgetOAuthDriver:

10. Email Restrictions

For providers that support email restrictions (like Google), implement SupportsEmailRestrictions:
The system includes a trait to simplify implementation:
Email Restrictions Features:
  • Invite Integration: Automatically configures email hints when OAuth is used for workspace invitations
  • Login Hints: Providers like Google receive login_hint parameter to pre-fill login form
  • Email Validation: Validates OAuth email matches invited email during authentication
  • Capability-based: Only applied to drivers that implement SupportsEmailRestrictions

OAuth Flow Types

Authentication Flow (User Login/Registration)

Key Features of New Flow:
  1. State Token Security: Each OAuth flow gets a unique, cryptographically secure state token
  2. Context Isolation: Context is stored with state token, preventing cross-request interference
  3. Invite Integration: Workspace invitations are validated and email restrictions applied automatically
  4. Automatic Cleanup: Context is cleared after successful use to prevent replay attacks
  5. Email Validation: For invites, OAuth email must match the invited email address
  6. Error Handling: Comprehensive error handling for expired contexts, invalid invites, email mismatches

Integration Flow (Connect Account)

Key Features:
  • Enhanced scopes: Automatically requests full permissions needed for integrations based on getScopesForIntent()
  • Context preservation: Stores intention, autoClose, and other settings using secure state tokens
  • Provider management: Creates/updates OAuthProvider records with full OAuth data
  • State security: Uses same state token security as authentication flows

Widget Flow (e.g., Telegram)

Widget Authentication Features:
  • No redirect flow: Authentication happens in-place via widget, no OAuth redirect required
  • Data verification: Cryptographic verification of widget data using provider-specific methods
  • Direct provider creation: Immediately creates provider records without state tokens (no callback URL)
  • Invite Integration: Supports workspace invitations with same email validation as redirect flows
  • Orchestrated Processing: Uses same OAuthFlowOrchestrator as redirect flows for consistency

Frontend Integration

Window Message Communication

The frontend uses useWindowMessage composable for cross-window communication:

OAuth Composable (useOAuth)

Centralized OAuth operations with TanStack Query integration:

Cache Management

The system automatically invalidates TanStack Query cache when OAuth connections change:

Adding a New Integration

Follow these steps to add a new OAuth provider to OpnForm:
1

Create OAuth Driver

Implement the OAuth driver class with the updated interface:
New Required Methods: All drivers must now implement setState() for security. Use SupportsEmailRestrictions interface and HasEmailRestrictions trait only if your provider supports email hints/restrictions (like Google’s login_hint parameter).
The setState() method is required for state token security. The orchestrator will automatically call this method with a secure state token before generating the redirect URL.
2

Register in Provider Service

Add your new provider to the enum:
3

Configure Services

Add configuration to api/config/services.php:
Add environment variables to .env.example:
4

Install Socialite Provider

If using a community Socialite provider, add it to composer.json:
Register in api/app/Providers/EventServiceProvider.php:
5

Add Frontend Service Definition

Update the frontend service configuration:
6

Add Feature Flag

Update feature flags controller to expose the provider:
7

Test the Integration

Test both authentication and integration flows with the new architecture:Authentication Test:
  1. Start fresh (logged out)
  2. Click “Sign in with New Provider”
  3. Verify state token is included in redirect URL
  4. Complete OAuth flow at provider
  5. Verify callback includes state token
  6. Check user creation and login success
  7. Verify context cleanup (state token should be cleared)
Integration Test:
  1. Log in with existing account
  2. Go to Settings → Connections
  3. Click “Connect New Provider”
  4. Verify integration scopes are requested (more permissions than auth)
  5. Complete OAuth flow
  6. Verify provider appears in connected accounts
  7. Check that provider record includes full OAuth data
Workspace Invitation Test (if applicable):
  1. Create a workspace invitation for a specific email
  2. Start OAuth flow with invite_token parameter
  3. Verify email restrictions are applied (if provider supports them)
  4. Complete OAuth with invited email address
  5. Verify user is added to correct workspace with proper role
Verify state tokens are generated, used for context storage, and cleaned up after use. Check that email restrictions work correctly for invite flows.
8

Add Integration Handler (Optional)

If your provider will be used for form integrations, create an integration handler:
Register the handler and add frontend integration components as needed.

Provider Normalization

Important: When creating providers that represent the same OAuth service but with different authentication methods (like Google OAuth vs Google One Tap), they should be normalized to the same provider name in the database.
OpnForm handles provider normalization through the getDatabaseProvider() method in the enum:
This ensures that:
  • Users can’t connect multiple “Google” accounts (regular OAuth + One Tap)
  • Provider scopes and permissions are properly merged
  • The same OAuth provider record is updated regardless of authentication method
  • Integration handlers work consistently with the normalized provider name
When adding new providers, consider if they should be normalized:
  • Same OAuth service, different auth methods: Normalize (like Google/GoogleOneTap)
  • Different OAuth services: Don’t normalize (like Google/GitHub)

Widget-Based Providers

For providers that use widget authentication (like Telegram), implement WidgetOAuthDriver:

Advanced Configuration

Request Validation

The system now uses OAuthRedirectRequest for structured validation:
Validation Features:
  • Intent Validation: Ensures only valid intents (auth or integration) are accepted
  • Invite Token: Validates workspace invitation tokens when present
  • Context Parameters: Validates additional context like intention and autoClose
  • UTM Tracking: Validates UTM data for analytics

Custom Scopes and Parameters

OAuth drivers can customize the authorization request with state tokens:

Error Handling

The system includes comprehensive error handling in the orchestrator:
Error Handling Features:
  • Provider Validation: Validates OAuth provider exists before processing
  • State Token Security: Returns 419 for expired or invalid state tokens
  • Context Cleanup: Automatically clears context even on errors
  • Email Validation: Returns specific errors for email mismatches in invite flows
  • Comprehensive Logging: All errors are logged for debugging

Troubleshooting

  • Check feature flag configuration in FeatureFlagsController
  • Verify environment variables are set
  • Ensure service is added to useOAuth services list
  • Check browser console for JavaScript errors
  • Verify redirect URL in config/services.php matches provider configuration - Check that APP_URL environment variable is correct - Ensure provider OAuth app is configured with correct callback URL
  • Check that the OAuth provider is returning the state parameter correctly
  • Verify that the OAuth flow completes within 5 minutes (context TTL) - Ensure the state token is being passed correctly in setState() method - Check cache configuration and ensure Laravel cache is working properly
  • Verify driver implements SupportsEmailRestrictions interface - Check that HasEmailRestrictions trait is being used correctly - Ensure getEmailRestrictionParameters() returns correct parameters for your provider - Test with a provider that supports login hints (like Google)
  • Check getScopesForIntent() method returns correct scopes - Verify provider OAuth app has necessary permissions enabled - Test with minimal scopes first, then add additional ones - Ensure intent is being passed correctly (auth vs integration)
  • Verify widget data signature verification logic - Check that widget script is loaded correctly - Ensure widget callback URL is accessible and correct - Test widget data extraction and user creation flow - Verify all required OAuthDriver interface methods are implemented (including setState())
  • Check that WorkspaceInviteService is properly handling invitations
  • Verify invite token validation in OAuthInviteService
  • Ensure email validation is working correctly for invite flows
  • Check that workspace and role assignment is working properly

Best Practices

Security

  • State Token Security: Always implement setState() method properly for CSRF protection - Context Cleanup: Trust the orchestrator to handle context cleanup automatically - Email Validation: Use SupportsEmailRestrictions for workspace invitation flows - Widget Verification: Always verify widget data signatures cryptographically - Minimal Scopes: Use minimal scopes for authentication, full scopes for integrations - Error Handling: Implement comprehensive error handling and logging

User Experience

  • Loading States: Provide clear loading states during OAuth flows - Email Hints: Use email restrictions to pre-fill login forms for better UX - Error Messages: Show specific, actionable error messages for OAuth failures - Auto-close: Use autoClose parameter appropriately for integration flows - Popup Handling: Handle popup blockers gracefully with fallback options

Performance

  • State Management: Trust the orchestrator’s efficient state token system - Context TTL: Keep OAuth flows under 5 minutes to avoid context expiration - Cache Integration: Use TanStack Query for efficient data fetching and cache invalidation - Service Architecture: Leverage the service-oriented architecture for better separation of concerns - Cleanup: Implement proper cleanup for event listeners and avoid memory leaks
This comprehensive architecture allows OpnForm to support any OAuth provider with a consistent, maintainable codebase that handles all the complexities of modern OAuth flows.