# 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](https://zato.io/docs/security/basic-auth.html) {#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](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 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 {#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 {#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 {#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.

## Learn more {#learn-more}

- [SAP integrations](https://zato.io/docs/dev/sap/) - Business entities as Python dicts, over OData V2 and V4
- [Querying SAP](https://zato.io/docs/dev/sap/query/) - Filters, paging, counting and related entities
- [S/4HANA and ECC](https://zato.io/docs/dev/sap/s4hana/) - Gateway services, their entity sets and what they expect
- [SuccessFactors](https://zato.io/docs/dev/sap/success-factors/) - The OData V2 API, its authentication and its quirks
- [SAP in enmasse](https://zato.io/docs/dev/sap/enmasse/) - Connections as YAML, with secrets read from the environment