SAP security
Basic Auth with technical users, Bearer tokens, OAuth2 client credentials and X-CSRF-Token handling.
Each outgoing SAP 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 scheme on-premise SAP systems commonly use - a technical user's name in the form and a password set through the Change password menu option.
- Auth type: Basic
- Username: the technical user's name
The technical user needs the authorizations of the Gateway services the connection calls - the relevant S_SERVICE entries and the business authorizations behind them.
Bearer tokens
When the token is issued outside of Zato - for instance by an API gateway or a BTP destination service in front of the SAP system - 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 SAP platforms - SuccessFactors, BTP-hosted services - 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://<host>/oauth/token - Client ID: the application's identifier
- Scopes: one or more scopes, when the platform requires them
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.
CSRF tokens
SAP Gateway systems require an X-CSRF-Token header with every write - POST, PATCH, MERGE or DELETE. New SAP connections have Needs CSRF token enabled by default and the client handles the whole exchange: it fetches a token with a HEAD request before the first write, caches it, and when the system 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. For systems that do not use the exchange, such as SuccessFactors, disable the checkbox in the connection's form.
TLS
Connections to systems with private or internal certificates may need the system's CA certificate uploaded to Zato first, because without it the certificate is rejected during the TLS handshake.