Authentications

Updated July 7, 2026

Connection details and credentials live in a separate object that ports reference by name, one Authentication type per Adapter type, application-scoped, encrypted at rest, optionally included when you snapshot the application.

An Authentication in Art2link ESB is the object that holds whatever a port's adapter needs to reach its endpoint, for a SQL Adapter that is the connection string, and every other adapter declares the shapes it accepts. The shape is determined by the Definition picked when the Authentication is created; the storage and lifecycle are the same in every case.

Authentications are deliberately separated from port and adapter configuration so the connection details can be defined once and referenced from every port that needs them. Each port carries the Authentication's name, not its value, editing the port's other properties does not require seeing or re-entering the secret, and rotating the secret in one place updates every port that uses it.

The same separation is what makes Snapshots safe to share, configuration moves between environments as plain JSON, and Authentications travel only when the operator opts in and supplies a password.

Design choice

One Authentication type per Adapter type

The pairing between Adapters and Authentications is one-to-one at the type level. Every Adapter type defines exactly one Authentication shape; an adapter cannot consume an Authentication that belongs to a different adapter type.

Take SQL as the worked example. A SQL Adapter on a port reaches its database through a SQL Authentication built on the SQL Server Connection Definition, whose Database Config holds the connection string. The pattern is the same throughout: pick the adapter and Definition, and the fields the Authentication exposes follow.

Practical effect. When you create an Authentication, the first thing you choose is the adapter type it pairs with. From that point on, the form's fields, validations, and the way the runtime hands the value to the adapter are all determined by that choice.

Reference

Where Authentications live

Authentications are scoped to an Application, owned by it alongside the other artifacts the Application carries, see the catalogue in the Applications article for the full inventory. From the application menu, the Authentications list shows every Authentication that belongs to that application. Each row has these columns:

Column	Description
Name	How the Authentication is referenced from a port. Names are unique within the application; they are how a port's adapter configuration points back at this object.
Definition	The credential shape this Authentication is built on, picked from the catalog the chosen Adapter offers: SQL Server Connection for a SQL Caller, API Listener Token for an API Listener, API Bearer Token or API Basic Authentication for an API Caller. The Definition pins the field shape and dictates which adapters are allowed to reference this Authentication.
Application	The application this Authentication belongs to. Authentications never cross application boundaries; this column appears only when no Application is selected, see Selected Application.

The list view follows the platform's Selected Application behavior, with an Application selected, the list filters to it and the Application column is hidden; with no selection, the list spans every Application you have access to and the column is shown. Creating a new Authentication uses the same flow: with an Application selected, the form opens with that Application preemptively chosen; without one, the form exposes an Application picker.

In the editor, the identity fields (Name, Adapter, Definition, Application) are followed by a Definition-specific config section holding the secret fields themselves; its heading follows the Definition, Partner Config with a Token for an API Listener Token, Database Config with a connection string for a SQL Server Connection, and so on. Ports reference the finished object statically by name; on the send side a port can instead resolve the Authentication name dynamically through a {{ }} binding per message. That choice is made on the port, in the adapter configuration’s Auth Config Type field, not here. Receive ports always reference statically; they cannot use a dynamic binding.

The Definition catalog today, growing as adapters gain shapes. Direction sets who decides: calling out, the remote endpoint dictates the shape you need; listening, you dictate what callers must present. Field-level detail lives in each adapter’s own article.

Adapter	Definitions
API Listener	API Listener Token
API Caller	API Bearer Token, API Basic Authentication
SQL Caller	SQL Server Connection
O365 Mail Sender	Microsoft Graph
SFTP Caller	SFTP Password Authentication

Field values are not in the list. The values an Authentication carries are never displayed in the list view; the list is a directory of references, and the values themselves are kept under encryption (see Encrypted at rest below).

Concept

Reuse across ports and adapters

A single Authentication can be referenced by any number of ports inside the application, as long as each of those ports uses an adapter of the matching type. Five ports all reaching the same endpoint share one Authentication; its values live in one place and one place only.

This is the practical reason the object exists. The alternative, embedding the values inside each port's adapter configuration, would mean as many copies of the secret as there are ports, as many places to update when something changes, and as many chances for the copies to drift.

Reuse boundary. Reuse is bounded by adapter type and by application. An Authentication cannot be referenced by an adapter of a different type, and an Authentication in Application A cannot be referenced from a port in Application B. If two applications need the same credential, define it in each.

Runtime

Encrypted at rest

Authentications are always encrypted at rest under a platform-managed key. Their values are written encrypted at save time and decrypted only when an adapter resolves the reference at execution time.

This is the default and there is no opt-out. The only place encryption changes shape is when an Authentication is exported as part of a Snapshot, where a second layer kicks in, see below.

In Snapshots

Authentications are one of the two parts of an application's configuration that Snapshots include only on request (the other is Constants values). Taking or exporting a snapshot exposes an Include authentications option:

Leave it unchecked and the snapshot captures everything except Authentications. Configuration travels as plain JSON; secrets stay behind.
Check it and every Authentication owned by the application is included, with the snapshot password-encrypted under a passphrase the operator supplies at creation or export time. The same passphrase is required to decrypt the file on import.

The platform-managed encryption that protects an Authentication at rest is replaced for the snapshot by this user-supplied password, that is what makes a snapshot file portable across environments without exposing the platform key. The full take / export / import flow, including what happens when the password is missing or forgotten, is documented in the Snapshots article.

⚠️

The snapshot password is unrecoverable. A snapshot can still be imported without it, the configuration comes through, but the encrypted Authentications are discarded and must be recreated on the destination application before the configuration can be applied.

That is the whole shape

Pick an adapter type, define a name, fill in the fields the adapter requires, save. Reference the Authentication by name from every port that needs the same connection. Encrypted at rest by default, included in a snapshot only when you ask, and password-protected when you do.