Skip to content

Identity Providers (Single Sign-on)

Omnistrate allows configuring Single Sign-on (SSO) for your Customer Portal. This feature enables end users to authenticate into the Customer Portal using existing identity provider credentials, such as Google, GitHub, Microsoft Entra, and many others.

For enterprise customers, this means they can leverage their existing enterprise identity (such as Microsoft Entra / Active Directory, Okta, Auth0, or Keycloak) to provide seamless authentication. This integration allows to maintain centralized user management, enforce corporate security policies, and provide a familiar login experience.

This feature is an addition to the username/password authentication mechanism provided by default. You can disable the default username/password authentication updating the Customer Portal configuration and rely solely on identity providers for user authentication.

What is OpenID Connect?

SSO uses the OpenID Connect protocol for authentication, which is built on top of OAuth 2.0 and provides standardized identity verification.

How OpenID Connect Authentication Works

When a user clicks on an identity provider login button in your Customer Portal, the following authentication flow occurs:

  1. Initiation: The user is redirected to the identity provider's authorization endpoint
  2. Authentication: The user authenticates with their identity provider (e.g., enters Google credentials)
  3. Authorization: The identity provider asks the user to authorize your application to access their profile information
  4. Callback: The identity provider redirects back to your User Portal with an authorization code
  5. Token Exchange: Omnistrate exchanges the authorization code for an access token and ID token at the provider's token endpoint
  6. User Information: Omnistrate retrieves the user's profile information from the provider's user info endpoint or the token
  7. Session Creation: A user session (JWT token) is created in your Customer Portal using the verified identity information

This flow ensures secure authentication while maintaining user privacy and following industry standards.

Supported Identity Providers

Omnistrate supports the following identity providers:

  • Google - Google Workspace and personal Google accounts
  • GitHub - GitHub OAuth applications
  • Amazon Cognito - AWS managed identity service
  • Microsoft Entra (formerly Azure AD) - Microsoft's identity platform
  • Okta - Enterprise identity management
  • Auth0 - Identity-as-a-Service platform
  • Keycloak - Open-source identity and access management
  • OpenID Connect - Any OpenID Connect compliant provider

Once the SSO Identity Provider(s) are configured, users can login to your SaaS application using the buttons on the login page.

Customer Portal SSO

Configuration Settings

When configuring an identity provider, you'll need to provide the following information:

Required Settings

  • Client ID: The client ID of the identity provider application
  • Client Secret: The client secret of the identity provider application

OpenID Connect Endpoints

The behavior of these endpoints depends on the provider type:

Fixed Endpoint Providers (Google, GitHub): These providers have well-known, fixed endpoints that Omnistrate automatically configures. You don't need to specify these endpoints manually as they are built into the platform.

Configurable Endpoint Providers (Amazon Cognito, Microsoft Entra, Okta, Auth0, Keycloak, Generic OpenID Connect): For these providers, you can specify custom endpoints or let Omnistrate auto-discover them from the provider's OpenID Connect discovery document.

  • Authorization Endpoint: OAuth2 endpoint to initiate the authentication request
  • Token Endpoint: Endpoint used to exchange authorization code for access and ID tokens
  • User Info Endpoint: Endpoint to fetch authenticated user's information

Optional Settings

These settings allow you to customize how the identity provider appears and behaves in your Customer Portal:

  • Scopes: OAuth scopes (space separated) defining what information will be accessed from the identity provider (e.g., openid email profile). This determines what user information Omnistrate can retrieve and display in the Customer Portal. Common scopes include:

    • openid: Required for OpenID Connect authentication flow (enables ID token generation)
    • email: Access to user's email address (displayed in user profile)
    • profile: Access to basic profile information like name and avatar (displayed in user profile and throughout the portal).

  • LoginButton Icon URL: A URL to a custom image used as the icon on the login button in your Customer Portal. This allows you to:

    • Brand the login experience with your identity provider's logo
    • Use custom icons that match your portal's design theme
    • Provide visual recognition for users familiar with the identity provider
    • If not specified, Omnistrate will use a default icon for the provider type

  • Login Button Text: Custom text displayed on the login button in your Customer Portal. This allows you to:

    • Customize the call-to-action text (e.g., "Continue with Google" vs "Sign in with Google")
    • Use language that matches your brand voice
    • Provide context-specific messaging for different user types
    • If not specified, Omnistrate will use default text like "Continue with [Provider Name]"

  • Email Identifiers: Configure specific email domains (comma-separated) that should authenticate using this provider (e.g., omnistrate.com, google.com). This setting:

    • Automatically directs users with matching email domains to this identity provider
    • Helps streamline the login experience for enterprise users
    • Can be used to enforce corporate authentication policies
    • Allows different email domains to use different identity providers
    • If not specified, the identity provider will be available to all users regardless of email domain

Provider Setup Instructions

For all identity providers, you must create an OAuth 2.0 Application configured for Web Applications. This is essential for the OpenID Connect authentication flow to work properly with your Customer Portal. Each provider has specific steps to create and configure these OAuth applications as detailed below.

Google

Google uses fixed, well-known OpenID Connect endpoints that are automatically configured by Omnistrate. You only need to provide the Client ID and Client Secret.

  1. Go to the Google Cloud Console
  2. Create a new project or select an existing one
  3. Enable the Google+ API
  4. Go to Credentials → Create Credentials → OAuth 2.0 Client IDs
  5. Configure the OAuth consent screen if not already done
  6. Set Application type to "Web application"
  7. Add your SaaS domain URL to Authorized JavaScript origins
  8. Add your SaaS domain URL with /idp-auth endpoint to Authorized redirect URIs
  9. Copy the Client ID and Client Secret

Fixed Endpoints (automatically configured):

  • Authorization: https://accounts.google.com/o/oauth2/v2/auth
  • Token: https://oauth2.googleapis.com/token
  • User Info: https://openidconnect.googleapis.com/v1/userinfo

Required Scopes: openid email profile

Documentation: Google OAuth 2.0 Setup

Note

If your Google application is set to "Internal" user type, only users within your organization (@your-organization.com) will be able to authenticate with this Identity Provider. Omnistrate is not able to verify your Identity Provider credentials in this case.

GitHub

GitHub uses fixed endpoints that are automatically configured by Omnistrate. You only need to provide the Client ID and Client Secret.

  1. Go to your GitHub account Settings → Developer settings → OAuth Apps
  2. Click New OAuth App
  3. Fill in the application details:
  4. Application name: Your SaaS application name
  5. Homepage URL: Your SaaS domain URL
  6. Authorization callback URL: Your SaaS domain URL with /idp-auth endpoint
  7. Click Register application
  8. Copy the Client ID and generate a Client Secret

Fixed Endpoints (automatically configured):

  • Authorization: https://github.com/login/oauth/authorize
  • Token: https://github.com/login/oauth/access_token
  • User Info: https://api.github.com/user

Required Scopes: read:user user:email

Documentation: GitHub OAuth Apps

Amazon Cognito

  1. Go to the AWS Cognito Console
  2. Select your User Pool or create a new one
  3. Go to App integration → App clients
  4. Create a new app client or select an existing one
  5. Configure the app client:
  6. Enable Authorization code grant
  7. Add your SaaS domain URL with /idp-auth to Allowed callback URLs
  8. Add required scopes: openid, email, profile
  9. Note down the Client ID and Client Secret
  10. Find your Cognito domain under App integration → Domain

Endpoints:

  • Authorization: https://your-domain.auth.region.amazoncognito.com/oauth2/authorize
  • Token: https://your-domain.auth.region.amazoncognito.com/oauth2/token
  • User Info: https://your-domain.auth.region.amazoncognito.com/oauth2/userInfo

Documentation: Amazon Cognito OAuth 2.0

Microsoft Entra (Azure AD)

  1. Go to the Azure Portal
  2. Navigate to Azure Active Directory → App registrations
  3. Click New registration
  4. Configure the application:
  5. Name: Your SaaS application name
  6. Supported account types: Choose appropriate option
  7. Redirect URI: Web - Your SaaS domain URL with /idp-auth
  8. Go to Certificates & secrets → Client secrets → New client secret
  9. Copy the Application (client) ID and Client secret value

Endpoints (replace {tenant-id} with your tenant ID):

  • Authorization: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize
  • Token: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
  • User Info: https://graph.microsoft.com/oidc/userinfo

Required Scopes: openid email profile

Documentation: Microsoft Identity Platform

Okta

  1. Go to your Okta Admin Console
  2. Navigate to Applications → Applications
  3. Click Create App Integration
  4. Select OIDC - OpenID Connect and Web Application
  5. Configure the application:
  6. App integration name: Your SaaS application name
  7. Grant type: Authorization Code
  8. Sign-in redirect URIs: Your SaaS domain URL with /idp-auth
  9. Copy the Client ID and Client secret

Endpoints (replace {your-okta-domain} with your Okta domain):

  • Authorization: https://{your-okta-domain}/oauth2/default/v1/authorize
  • Token: https://{your-okta-domain}/oauth2/default/v1/token
  • User Info: https://{your-okta-domain}/oauth2/default/v1/userinfo

Required Scopes: openid email profile

Documentation: Okta OIDC Web App

Auth0

  1. Go to your Auth0 Dashboard
  2. Navigate to Applications → Applications
  3. Click Create Application
  4. Choose Regular Web Applications
  5. Go to the Settings tab:
  6. Allowed Callback URLs: Your SaaS domain URL with /idp-auth
  7. Allowed Web Origins: Your SaaS domain URL
  8. Copy the Client ID and Client Secret

Endpoints (replace {your-auth0-domain} with your Auth0 domain):

  • Authorization: https://{your-auth0-domain}/authorize
  • Token: https://{your-auth0-domain}/oauth/token
  • User Info: https://{your-auth0-domain}/userinfo

Required Scopes: openid email profile

Documentation: Auth0 Regular Web App

Keycloak

  1. Access your Keycloak Admin Console
  2. Select your realm or create a new one
  3. Go to Clients → Create client
  4. Configure the client:
  5. Client type: OpenID Connect
  6. Client ID: Your application identifier
  7. In the client settings:
  8. Access Type: Confidential
  9. Valid Redirect URIs: Your SaaS domain URL with /idp-auth
  10. Web Origins: Your SaaS domain URL
  11. Go to Credentials tab and copy the Secret

Endpoints (replace {keycloak-server} and {realm} with your values):

  • Authorization: https://{keycloak-server}/auth/realms/{realm}/protocol/openid-connect/auth
  • Token: https://{keycloak-server}/auth/realms/{realm}/protocol/openid-connect/token
  • User Info: https://{keycloak-server}/auth/realms/{realm}/protocol/openid-connect/userinfo

Required Scopes: openid email profile

Documentation: Keycloak OpenID Connect

Generic OpenID Connect

For any OpenID Connect compliant provider:

  1. Register your application with the identity provider
  2. Configure the redirect URI to your SaaS domain URL with /idp-auth
  3. Obtain the Client ID and Client Secret
  4. Find the OpenID Connect discovery document (usually at /.well-known/openid_configuration)
  5. Extract the required endpoints from the discovery document

Required Information:

  • Client ID and Client Secret
  • Authorization Endpoint
  • Token Endpoint
  • User Info Endpoint
  • Supported scopes (minimum: openid email, recommended: openid email profile)

Setting Up Identity Providers in Omnistrate

  1. Navigate to the Identity Providers section in Omnistrate
  2. Click Add Identity Provider
  3. Select your identity provider from the dropdown
  4. Fill in the required configuration:
  5. Client ID: From your identity provider application
  6. Client Secret: From your identity provider application
  7. Scopes: Required scopes (typically openid email profile)
  8. Endpoints: Auto-filled for known providers, manual entry for generic OpenID Connect
  9. Configure optional settings:
  10. Login Button Text: Custom text for the login button
  11. Login Button Icon URL: Custom icon for the login button
  12. Email Identifiers: Restrict to specific email domains
  13. Click Verify to test the configuration
  14. Click Save to enable the identity provider

Advanced Security Features

By integrating with enterprise identity providers, you can bring advanced security features to your Customer Portal:

SAML Support

Many identity providers (such as Microsoft Entra, Okta, Auth0, and Keycloak) support SAML (Security Assertion Markup Language) authentication. When users authenticate through these providers, they benefit from SAML's enterprise-grade security features, including:

  • Single Sign-On across multiple applications
  • Centralized user management and provisioning
  • Advanced session management and timeout policies
  • Detailed audit trails and compliance reporting

Multi-Factor Authentication (MFA)

Identity providers that support MFA can automatically extend this security to your Customer Portal. When configured at the identity provider level, users will be required to complete additional authentication factors such as:

  • SMS or email verification codes
  • Authenticator app tokens (Google Authenticator, Microsoft Authenticator, etc.)
  • Hardware security keys (FIDO2/WebAuthn)
  • Biometric authentication
  • Push notifications to mobile devices

The MFA enforcement is handled entirely by the identity provider, so no additional configuration is needed in Omnistrate once the identity provider is set up.

Disabling Default Authentication

For organizations that want to enforce SSO-only access, you can disable the default username/password authentication mechanism in your Customer Portal settings. This ensures that all users must authenticate through your configured identity providers, providing:

  • Centralized access control
  • Consistent security policies
  • Simplified user management
  • Enhanced compliance with corporate security requirements

Troubleshooting

Common Issues

  • Invalid redirect URI: Ensure the redirect URI in your identity provider matches exactly: https://your-saas-domain.com/idp-auth
  • Scope errors: Make sure you've included the required scopes: openid email profile
  • Domain restrictions: Check if your identity provider has domain restrictions that might block authentication
  • HTTPS requirement: Most identity providers require HTTPS for production use, Omnistrate ensures this is configured for the SaaS Portal, but if you are running the portal on your own environment (in particular in development environments) pls be mindful of this restriction.

Testing Your Configuration

Omnistrate performs best effort validation of your identity provider configuration while you enter the data. This includes checking the format of URLs, validating required fields, and testing connectivity to endpoints where possible. However, we strongly recommend thorough testing in a development environment before enabling identity providers in production.

Important

While Omnistrate validates configuration data during entry, the complete authentication flow can only be fully tested with real user interactions. Always perform comprehensive testing in development before enabling in production environments.

For additional support, contact us at support@omnistrate.com.