Skip to Content

User authentication methods in Jitterbit App Builder

Overview

User authentication is the process of verifying the identity of someone trying to access an application. It determines who can sign in, under what conditions, and with what level of trust. Choosing the right authentication method for your application determines the specifics of how the sign-in process takes place, what capabilities come built in, and how much custom development your team is responsible for.

App Builder supports these six user authentication methods:

In addition to the authentication methods themselves, this page also introduces the related concepts of user provisioning, which concerns how to programmatically create user accounts, and provider security groups, which involves mapping groups defined by an external identity provider to App Builder security groups.

User authentication methods

Single sign-on

Single sign-on (SSO) lets users authenticate with App Builder using credentials they already manage in a third-party identity provider, such as Microsoft Entra ID or Okta. Instead of maintaining a separate App Builder password, users authenticate through the identity provider, which then confirms their identity to App Builder. SSO also supports user and group provisioning: identity provider roles or group claims can be mapped to App Builder security groups, so permissions are applied automatically at sign-in.

App Builder supports SSO through the following protocols, each with a dedicated configuration guide:

Compatible identity providers include Microsoft Entra ID, Okta, Salesforce, Symantec SiteMinder (formerly CA SiteMinder), and other OAuth2-compatible providers.

Local user authentication

Local authentication is App Builder's built-in authentication method. Users sign in with a username and password that are stored and managed directly within App Builder. This authentication method does not involve any external identity providers or directory services.

When you use local authentication, App Builder handles all steps of the authentication process: creating user accounts, storing passwords securely, enforcing password policies, and providing password recovery options. It is a suitable choice for scenarios where a centralized identity provider is not available or not required.

For a detailed walkthrough of managing users and groups with local authentication, see User and group management: local authentication.

Windows integrated authentication

Windows integrated authentication (WIA) allows users on a Windows domain to sign in to App Builder without entering credentials explicitly. When a user is already logged into their Windows domain, the browser passes their session credentials to the web server automatically. The web server validates those credentials against the domain and maps the Windows identity to an App Builder user account.

Because authentication relies on the user's active Windows session, there is no login form. This method is suited for intranet environments where all users are on domain-joined machines.

For setup instructions, see Configure integrated Windows authentication.

Active Directory

Active Directory authentication allows users to sign in to App Builder using their existing domain credentials (username and password). Unlike Windows integrated authentication, which relies on the user's active Windows session, this method uses a standard login form where users enter their credentials explicitly. The web server validates those credentials against the Active Directory domain and maps the identity to an App Builder user account.

This method works in environments where users are not on domain-joined machines, or where an explicit login form is required.

For configuration details, see Security provider - Active Directory.

Application authentication (custom)

Application authentication is a custom authentication method in which the developer builds and controls the entire sign-in process. Instead of redirecting users to a third-party identity provider, App Builder redirects them to a page within the application itself.

Unlike local authentication and SSO, application authentication provides no built-in capabilities. The developer is responsible for every aspect of the flow, including:

  • Capturing and validating user credentials.

  • Implementing multi-factor authentication (MFA) if required.

  • Creating and provisioning user accounts.

  • Assigning users to groups and configuring the associated permissions.

  • Building password reset and account recovery flows.

  • Enforcing password policies.

This approach is suitable when credentials need to be validated against an external data source, when semi-anonymous access is required, or when the authentication logic cannot be handled by a standard provider. This approach requires significantly more development work than the other authentication methods.

For a detailed guide on setting up application authentication, see Security provider - application authentication.

Anonymous access

Anonymous access allows users to reach an application without authenticating. In App Builder, any request that is not associated with a signed-in user is automatically handled under the "anonymous" user account. Developers can assign specific permissions to this account to control what content is publicly accessible.

Anonymous authentication is enabled by default. It is useful for scenarios such as public-facing pages, landing pages, or custom login screens that must be accessible before a user signs in.

To configure which parts of your application anonymous users can access, see Anonymous access. To configure a data source to allow unauthenticated connections, see HTTP anonymous authentication.

Identity management

User provisioning

User provisioning is a mechanism for creating App Builder user accounts programmatically, without requiring manual creation through the IDE. It is not an authentication method, but it is commonly used alongside authentication flows to create accounts on demand.

Because App Builder does not allow CRUD rules to write directly to its user and group tables, it exposes a public data object called User_Create for this purpose. Developers can build XP CRUD rules that insert records into User_Create to create new user accounts.

Each insert into User_Create requires a ProviderId, which identifies the security provider configuration to use for the new account. This allows security administrators to define the authorization policies applied to new accounts independently of how the developer implements the account creation logic.

For more details, see User and group provisioning.

Provider security groups

Many external authentication providers define their own security groups, sometimes referred to as roles or scopes. App Builder allows security administrators to map these provider-defined groups to App Builder security groups, so that a user's permissions within App Builder reflect their group membership in the external provider.

Each provider security group mapping has the following properties:

  • Provider: The security provider (user or data source) to which the group belongs.

  • Identifier: The unique name assigned to the group by the security provider.

  • Group: The App Builder security group to which the provider group is mapped.