# OData security

Basic Auth, Bearer tokens, OAuth2 client credentials and SAP CSRF tokens for outgoing OData connections.

Each outgoing OData connection has its own authentication settings - pick the auth type in the connection's form and fill in the fields the type requires. The client applies the credentials to every request, refreshes what expires and retries what a stale token rejected, all without any code in services.

## [Basic Auth](https://zato.io/docs/security/basic-auth.html) {#basic-auth}

The simplest scheme - a username in the form and a password set through the **Change password** menu option. This is what on-premise SAP systems and Business Central sandboxes commonly use.

- Auth type: Basic
- Username: the technical user's name

## [Bearer tokens](https://zato.io/docs/security/bearer-tokens/index.html) {#bearer-tokens}

When the token is issued outside of Zato - for instance by an API gateway in front of the OData service - select Bearer and set the token through **Change password**. The client sends it as `Authorization: Bearer ...` with each request.

- Auth type: Bearer

## OAuth2 client credentials {#oauth2-client-credentials}

Cloud platforms - SuccessFactors, Dynamics 365, Business Central online - authenticate applications with the OAuth2 client credentials grant. The client obtains a token from the token URL, caches it, and fetches a fresh one before the cached one expires. If a server rejects a request with 401 despite a cached token, the token is refreshed and the request retried once.

- Auth type: OAuth2
- Token URL: where tokens are issued, e.g. `https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token`
- Tenant ID: for Microsoft Entra ID tenants - when given, it is substituted into the token URL
- Client ID: the application's identifier
- Scopes: one or more scopes, e.g. `https://api.businesscentral.dynamics.com/.default`

The client secret is set through **Change password** - like all secrets in Zato, it is stored encrypted and never appears in configuration files or logs.

## SAP CSRF tokens {#sap-csrf-tokens}

SAP Gateway systems require an X-CSRF-Token header with every write - POST, PATCH, MERGE or DELETE. Enable **Needs CSRF token** in the connection's form and the client handles the whole exchange: it fetches a token with a HEAD request before the first write, caches it, and when the server responds with 403 and `x-csrf-token: Required`, fetches a fresh token and retries.

Nothing changes in service code - conn.create, conn.update and conn.delete work the same with and without CSRF handling.

## TLS {#tls}

Connections to servers with private or internal certificates may need the server's CA certificate uploaded to Zato first, because without it the certificate is rejected during the TLS handshake.

## Learn more {#learn-more}

- [OData integrations](https://zato.io/docs/dev/odata/) - Entity sets as Python dicts, across OData V2 and V4 systems
- [Query options](https://zato.io/docs/dev/odata/query/) - Filters, ordering, paging, expansion and counting
- [The systems you meet](https://zato.io/docs/dev/odata/systems/) - Business Central, Dynamics 365 and other OData services
- [OData tutorial](https://zato.io/tutorials/odata.html) - From an empty connection to reading and writing records