# Outgoing connections security

Authenticate outgoing REST, SOAP and other connections with the type the remote system expects.

Zato services call external systems through outgoing connections - REST, SOAP, [GraphQL](https://zato.io/docs/dev/examples/graphql.html), IMAP, SQL, ElasticSearch and the other connection types. Each connection pairs the address that it calls with the credentials that the remote system expects, so authentication is part of the connection's definition, not of your code.

A single security definition may cover any number of outgoing connections, and changes to connections or definitions take effect without restarts.

## Use security definitions {#use-security-definitions}

You create a security definition first, under the `Security` menu in the Dashboard, and assign it when you create or edit an outgoing connection of the matching type:

## Choose a security type {#choose-a-security-type}

An outgoing connection proves who Zato is to the remote system, so pick the type that the system expects:

| Type | What Zato sends | Use it when |
| --- | --- | --- |
| [Basic Auth](https://zato.io/docs/security/basic-auth.html) | A username and password in the `Authorization` header | The remote system issued you credentials |
| [API key](https://zato.io/docs/security/api-keys.html) | A key in a header, `X-API-Key` by default | The remote system issued you a key |
| [Bearer token](https://zato.io/docs/security/bearer-tokens/index.html) | An OAuth 2.0 bearer token | The remote system uses OAuth 2.0 |
| mTLS | A client certificate | The remote system authenticates callers by certificate - see [mTLS](https://zato.io/docs/security/mtls/index.html) |
| [NTLM](https://zato.io/docs/security/ntlm.html) | NTLM credentials, usually `DOMAIN\user` | The remote system is a Windows service expecting NTLM |
| Kerberos (SPNEGO) | A Kerberos ticket from a keytab | The remote system is on a Kerberos realm - see [Kerberos](https://zato.io/docs/security/kerberos/index.html) |

NTLM and Kerberos are outgoing-only - they authenticate Zato to a remote system and cannot secure a [channel](https://zato.io/docs/admin/security/channel.html).

Not every connection type takes every security type:

| Connection type | Basic Auth | API key | Bearer token | mTLS | NTLM | Kerberos |
| --- | --- | --- | --- | --- | --- | --- |
| REST | Yes | Yes | Yes | Yes | Yes | Yes |
| SOAP | Yes | Yes | Yes | Yes | Yes | Yes |
| HL7 FHIR | Yes | - | Yes | - | - | - |
| GraphQL | Yes | Yes | Yes | - | - | - |

The remaining outgoing types - SQL, IMAP, SMTP, LDAP, SFTP, MongoDB, Odoo and the other connection-specific types - do not use security definitions at all. Each has its own credentials, a username and password entered on the connection itself - you change the password through the connection's `Change password` action.

## Timeouts and retries {#timeouts-and-retries}

Set a timeout on every outgoing connection, so that a remote system that stops responding does not become your own outage. A connection with retries configured retries its [health check](https://zato.io/docs/admin/health-checks.html) too, so a long retry policy delays the point at which the health check reports a failure.

## Automation with enmasse {#automation-with-enmasse}

Once the connections work, export them with [enmasse](https://zato.io/docs/admin/enmasse.html) - the YAML holds the definitions and connections without any passwords, and importing it from the command line recreates the setup in any environment.

## See also {#see-also}

- [Channel security](https://zato.io/docs/admin/security/channel.html) - Authenticating the callers of your own APIs
- [mTLS](https://zato.io/docs/security/mtls/index.html) - Client certificates on both channels and outgoing connections
- [Health checks](https://zato.io/docs/admin/health-checks.html) - How retries on a connection delay failure reports

## Learn more {#learn-more}

- [Production checklist](https://zato.io/docs/admin/production-checklist.html) - What to confirm before an environment takes real traffic
- [Audit log](https://zato.io/docs/admin/audit-log/) - Every request, response and error, and what you can do with them afterwards
- [Health checks](https://zato.io/docs/admin/health-checks.html) - Have Zato ping your outgoing connections instead of waiting for traffic to fail
- [Logging](https://zato.io/docs/admin/logging.html) - What is written where, and how to ship it to Splunk, Loki, Elastic or Datadog
- [GitOps with enmasse](https://zato.io/docs/admin/enmasse.html) - Keep the whole environment in git as YAML and import it anywhere