OAuth & OpenID Connect (OIDC)
Sign in with Google, Microsoft, or your corporate identity provider via SAML 2.0 or OIDC
Overview
Instafill.ai supports OAuth 2.0 and OpenID Connect for both individual sign-in and enterprise SSO. Users can authenticate with Google or Microsoft without a separate Instafill.ai password. Enterprise organizations can connect their own identity provider via SAML 2.0 or OIDC so employees sign in through existing corporate credentials.
After any successful authentication - regardless of method - the system issues a JWT. This token is validated on every subsequent request by middleware running in both the .NET API layer and the Python processing service, so the same credential is honored consistently across both service layers.
Full details on all supported sign-in methods, 2FA, and password handling are on the Authentication & Security page.
Key Capabilities
- Google OAuth: Users sign in with their Google account - no Instafill.ai password required; only the identity assertion is exchanged
- Microsoft OAuth: Same pattern as Google - no Microsoft password is transmitted to Instafill.ai
- SAML 2.0: Enterprise SSO via SAML 2.0 (XML-based); works with Azure AD, Auth0, Okta, and other major identity providers
- OIDC: Enterprise SSO via OpenID Connect (JWT-based); same IdP compatibility as SAML
- Unified JWT Issuance: Every authentication method produces the same JWT format, validated by shared middleware across both service layers
- Security Validations: Token signature verification, issuer and audience checks, and expiration enforcement applied on every request
How It Works
Sign in with Google or Microsoft:
- User clicks "Sign in with Google" or "Sign in with Microsoft"
- The provider flow initiates the OAuth handshake with the external IdP
- The IdP returns an identity assertion (email, display name) - no password is transmitted to Instafill.ai
- The identity is mapped to an Instafill.ai account and a JWT is issued
- The JWT is validated on every subsequent request by middleware in both service layers
Enterprise SSO via SAML 2.0 or OIDC:
- Organization admins configure their identity provider (Azure AD, Auth0, Okta, or any compatible IdP)
- Employees click the SSO sign-in option and are redirected to the corporate IdP
- After authenticating with the IdP, the identity assertion is returned to Instafill.ai
- Instafill.ai validates the assertion - token signature, issuer, audience, and expiration - and issues a JWT
- From the employee's perspective, they log in once to their corporate IdP and land directly in their workspace
Use Cases
A healthcare organization requires all staff to authenticate through their existing Azure AD instance - Instafill.ai is configured as a SAML 2.0 service provider, and no employee needs a separate Instafill.ai password. When an employee leaves and their Azure AD account is disabled, access to Instafill.ai is revoked automatically through the IdP.
A technology company using Okta for identity management connects Instafill.ai via OIDC so developers accessing the platform through the API authenticate through the same corporate credential used for all other internal tools.
Individual users and small teams use Google or Microsoft sign-in to avoid managing another username and password.
Benefits
- No Extra Passwords: Google, Microsoft, and SSO sign-in methods mean most users never need a separate Instafill.ai credential
- Centralized Access Control: Enterprise IdP integration means user provisioning and deprovisioning happens in one place - the identity provider
- Broad IdP Compatibility: SAML 2.0 and OIDC support covers Azure AD, Auth0, Okta, and any other standards-compliant identity provider
- Consistent Security Enforcement: The same JWT validation runs across both service layers regardless of which sign-in method was used
Security & Privacy
All authentication events produce a JWT validated by middleware across both the .NET and Python service layers. Token signature verification, issuer and audience checks, and expiration enforcement are applied on every request. No third-party passwords are transmitted to or stored by Instafill.ai - only the identity assertion returned by the IdP is used.
All session data is scoped to workspaceId and protected by the shared JWT authentication middleware.
Common Questions
Which identity providers are supported for enterprise SSO?
Instafill.ai supports SAML 2.0 and OIDC for enterprise SSO. Confirmed compatible identity providers include Azure AD, Auth0, and Okta. Any identity provider that supports SAML 2.0 or OIDC can be configured. Contact the sales team to set up SSO for your organization.
What is the difference between SAML 2.0 and OIDC?
Both protocols enable enterprise SSO but use different formats. SAML 2.0 is XML-based and is the more established standard, widely supported by enterprise IdPs. OIDC is JWT-based and is the more modern standard, often preferred for newer integrations. Instafill.ai supports both - the choice depends on what your identity provider supports and your organization's preference.
Can I use both SSO and API key authentication?
Yes. SSO and OAuth control how users sign in to the Instafill.ai web application. API keys are used separately for server-to-server integrations via the REST API. Both authentication methods produce tokens validated by the same middleware, so they work independently alongside each other.