Authentication in Unqork

Unqork supports authentication in three distinct contexts. Each context has a different direction and a different set of tools. Understanding which context applies makes it easier to find the right configuration in the platform.

The Three Authentication Contexts

Authentication in Unqork flows in one of three directions: outbound to an external system, inbound from an external system, or from an end-user. Each direction has its own administration area and its own supported methods. Choosing the wrong context is the most common source of confusion when setting up authentication for the first time.

Learn more about the three authentication contexts below:

Context 1: Unqork Calling External Systems

When a module calls an external API or service, Unqork must authenticate to that system. This is configured in Services Administration, found under Administration > Integration > Services Administration.

Each service has an authentication method. Creators choose between the following:

• Standard authentication uses one of Unqork's built-in protocols, like Basic Authentication, Bearer Token, or OAuth 2.0. The full list of supported types and their configuration fields is in Service Types.

• Custom authentication uses a custom authenticator configured separately in the environment. This option supports non-standard or proprietary authentication schemes.

When to use Standard vs. Custom: Standard covers the majority of REST APIs and  platforms. Use Custom only when the external system requires a proprietary scheme, like HMAC-signed headers or a non-standard token exchange, that Standard protocols do not support.

For more information, see Services Administration.

Context 2: External Systems Calling Unqork

When an external system calls the Unqork API, it must authenticate to Unqork. This is configured in API Access Management, found under Administration > Integration > API Access Management.

API Access Management uses the OAuth 2.0 client credentials flow. An administrator creates a credential that contains a client ID and a client . The external system uses these values to request an access token before making API calls.

Unqork supports the following credential types:

• Express credentials: Grant access as an Express user, with one or more Express roles assigned.

• Creator credentials: Grant access as a Creator, with a single Creator role assigned.

When to use Express vs. Creator credentials: Use Express credentials when the integration acts as an end-user, accessing application data or triggering workflows governed by Express roles. Use Creator credentials when the integration requires platform-level access, like managing modules or querying the environment through Creator APIs.

For more information, see API Access Management.

Context 3: End-Users Accessing an Application

When end-users log in to a Unqork application, several authentication options are available. The right choice depends on whether the environment uses an external identity provider and whether end-users need persistent accounts.

Single Sign-On

SSO (Single Sign-On) lets end-users authenticate through an external identity provider (IdP) like Okta or Microsoft Entra ID. Unqork supports SAML 2.0 and OIDC (OpenID Connect).

Unqork has the following SSO domains:

• Designer SSO controls how Creators log in to the platform.

• Express SSO controls how end-users log in to applications. The two domains are configured independently and can use different identity providers.

When to use SSO: Use SSO when end-users already have accounts in an organizational identity provider. This is the right choice for enterprise or internal deployments where the organization controls the IdP. It avoids creating and managing separate Unqork accounts for each end-user.

For more information, see Setting Up Single Sign-On (SSO) in Unqork and SSO Concepts.

Express Users

Express Users are end-user accounts managed directly in Unqork. Administrators create and manage these accounts in Express User Administration, found under Administration > Express Permissions > Express User Administration.

This option does not require an external identity provider. Each account is assigned one or more Express roles, which control what end-users can access in an application.

When to use Express Users: Use Express Users when end-user accounts are managed directly in Unqork without an external IdP. This is common for external-facing applications, customer portals, or deployments where the organization does not have an IdP or does not want to integrate one.

For more information, see Express User Administration.

Refer Strings

A refer string is a URL-based authentication method for temporary access. An encrypted token is appended to a URL, which grants access to a specific application or module without requiring an end-user account. Refer strings are commonly used for registration links or one-time access flows.

When to use Refer Strings: Use Refer Strings for one-time or temporary access scenarios: registration flows, external invite links, or approval requests sent by email. Refer strings are not a substitute for persistent end-user accounts. Sessions expire and cannot be individually revoked after they are issued.

For more information, see Understanding and Configuring Refer Strings.

Which Context Applies?

Use the following table to identify the right context for a given situation.

For end-users accessing an application, use the table below to choose the right method.