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
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
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
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 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
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.