---
# === IDENTITY ===
id: business/erp-integration/sap-authentication-methods/2026
canonical_question: "What authentication methods does SAP S/4HANA support (OAuth, X.509, SAML) by deployment model?"
aliases:
  - "SAP S/4HANA authentication options by deployment model"
  - "How to authenticate API calls to SAP S/4HANA Cloud and on-premise"
  - "SAP OAuth 2.0 SAML Bearer vs Client Credentials for S/4HANA"
  - "SAP S/4HANA Cloud certificate-based authentication mTLS setup"
entity_type: erp_integration
domain: business > erp-integration > sap-authentication-methods
region: global
jurisdiction: global
temporal_scope: 2024-2026

# === SYSTEM PROFILE ===
systems:
  - name: "SAP S/4HANA"
    vendor: "SAP"
    version: "2025 / 2H 2025"
    edition: "Public Cloud, Private Cloud, On-Premise"
    deployment: "hybrid"
    api_surface: "OData, SOAP, RFC"

# === VERIFICATION ===
last_verified: 2026-03-01
confidence: 0.88
version: 1.0
first_published: 2026-03-01

# === TEMPORAL VALIDITY ===
temporal_validity:
  status: volatile
  last_breaking_change: "2025-Q3 — Basic Auth deprecated for S/4HANA Cloud Public Edition inbound APIs"
  next_review: 2026-08-28
  change_sensitivity: high

# === CONSTRAINTS ===
constraints:
  - "Basic Authentication is deprecated for inbound API access on S/4HANA Cloud Public Edition — use OAuth 2.0 or mTLS instead"
  - "S/4HANA Cloud Public Edition does not support Kerberos/SPNEGO — only available on-premise and Private Cloud"
  - "OAuth 2.0 on S/4HANA Cloud Public Edition only supports Client Credentials and SAML Bearer Assertion grant types — no Authorization Code or Implicit flows"
  - "X.509 client certificates for S/4HANA Cloud must be CA-signed — self-signed certificates are rejected"
  - "SAP is migrating from XSUAA to IAS (Identity Authentication Service) — all new BTP apps should use IAS; XSUAA deadline November 2026 for SuccessFactors"
  - "Principal propagation requires pre-established trust between sender and receiver systems — cannot propagate identity across untrusted boundaries"

# === SKIP CONDITIONS ===
skip_this_unit_if:
  - condition: "User needs Salesforce or Oracle ERP authentication methods"
    use_instead: "business/erp-integration/salesforce-rest-api/2026 or business/erp-integration/oracle-erp-cloud-api/2026"
  - condition: "User needs SAP BTP application security (not S/4HANA backend)"
    use_instead: "business/erp-integration/sap-btp-security/2026"
  - condition: "User needs SAP authorization/role model (not authentication)"
    use_instead: "business/erp-integration/sap-authorization-model/2026"

# === AGENT HINTS ===
inputs_needed:
  - key: deployment_model
    question: "Which SAP S/4HANA deployment model are you using?"
    type: choice
    options:
      - "Public Cloud"
      - "Private Cloud (RISE)"
      - "On-Premise"
  - key: integration_type
    question: "What type of integration authentication do you need?"
    type: choice
    options:
      - "System-to-system (technical user, no human context)"
      - "User-context (principal propagation, SSO)"
      - "Interactive SSO (browser-based, SAP GUI)"
  - key: security_requirement
    question: "What is your security requirement level?"
    type: choice
    options:
      - "Standard (OAuth with client secret)"
      - "High (certificate-based / mTLS)"
      - "Enterprise SSO (SAML/Kerberos federation)"

# === DISTRIBUTION ===
canonical_source: "https://knowledgelib.io/business/erp-integration/sap-authentication-methods/2026"
suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-03-01)"

# === RELATED UNITS ===
related_kos:
  depends_on: []
  related_to:
    - id: "business/erp-integration/sap-s4hana-odata-api/2026"
      label: "SAP S/4HANA OData API capabilities and rate limits"
  solves: []
  alternative_to: []
  often_confused_with:
    - id: "business/erp-integration/sap-btp-security/2026"
      label: "SAP BTP application security (XSUAA/IAS) — platform-level, not backend"

# === SOURCES (7 authoritative sources) ===
sources:
  - id: src1
    title: "Set Up Authentication for SAP S/4HANA Cloud Extensions"
    author: SAP
    url: https://help.sap.com/doc/6ce62b6bdda340ffbeae3f138c3cb71b/SHIP/en-US/Set_Up_Authentication_for_SAP_S4HANA_Cloud_Extensions.pdf
    type: official_docs
    published: 2025-12-01
    reliability: authoritative
  - id: src2
    title: "S/4HANA Cloud APIs with ClientCertificateAuthentication"
    author: SAP
    url: https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/s-4hana-cloud-apis-with-clientcertificateauthentication/ba-p/13514464
    type: technical_blog
    published: 2024-06-15
    reliability: high
  - id: src3
    title: "SAP Integration Suite — Connecting to S/4HANA Private Cloud OData with OAuth (Client Credentials)"
    author: SAP
    url: https://community.sap.com/t5/technology-blog-posts-by-sap/sap-integration-suite-connecting-to-s-4hana-private-cloud-odata-with-oauth/ba-p/14295261
    type: technical_blog
    published: 2025-09-10
    reliability: high
  - id: src4
    title: "Complete Guide to SAP S/4HANA APIs: REST and SOAP Integration Tutorial"
    author: Apideck
    url: https://www.apideck.com/blog/guide-to-sap-4-hana-rest-and-soap-api
    type: technical_blog
    published: 2025-04-01
    reliability: moderate_high
  - id: src5
    title: "SAP Single Sign-On: Authenticate with Kerberos/SPNEGO"
    author: SAP
    url: https://community.sap.com/t5/technology-blog-posts-by-sap/sap-single-sign-on-authenticate-with-kerberos-spnego/ba-p/13321445
    type: technical_blog
    published: 2023-05-15
    reliability: high
  - id: src6
    title: "SAP's New Identity and Access Management Strategy: IAS + AMS vs XSUAA"
    author: adesso business consulting
    url: https://blog.adesso-bc.com/saps-new-identity-and-access-management-strategy/
    type: industry_report
    published: 2025-10-09
    reliability: moderate_high
  - id: src7
    title: "Demystifying the OAuth2 SAML Bearer Assertion Usage in SAP Integration Suite"
    author: SAP
    url: https://community.sap.com/t5/technology-blog-posts-by-sap/demystifying-the-oauth2-saml-bearer-assertion-usage-in-sap-integration/ba-p/14177915
    type: technical_blog
    published: 2025-06-20
    reliability: high
---

# SAP S/4HANA Authentication Methods by Deployment Model

## TL;DR

- **Bottom line**: SAP S/4HANA supports six authentication methods, but availability varies drastically by deployment model — Public Cloud is limited to OAuth 2.0 (Client Credentials or SAML Bearer) and mTLS; on-premise adds Kerberos/SPNEGO and full X.509/SNC flexibility.
- **Key limit**: Basic Auth is deprecated for S/4HANA Cloud Public Edition inbound APIs — any new integration must use OAuth 2.0 or certificate-based authentication. [src1]
- **Watch out for**: Confusing BTP-level authentication (XSUAA/IAS) with S/4HANA backend authentication — they are different layers, and both must be configured for end-to-end integration flows. [src6]
- **Best for**: Architects and integration developers choosing the right authentication flow for system-to-system or user-context integrations across any S/4HANA deployment model.
- **Authentication**: OAuth 2.0 Client Credentials for system-to-system (no user context); SAML Bearer Assertion for principal propagation; mTLS (X.509) for highest-security environments. [src1, src4]

## System Profile

This card covers authentication methods across all three SAP S/4HANA deployment models: Public Cloud, Private Cloud (RISE with SAP), and on-premise. Authentication availability varies significantly between these models — Public Cloud is the most restrictive, on-premise the most flexible. The card addresses both inbound authentication (external systems calling S/4HANA APIs) and outbound authentication (S/4HANA calling external services), as well as interactive SSO for browser and SAP GUI access.

SAP's identity strategy is actively shifting from XSUAA (Extended User Account and Authentication) to SAP IAS (Identity Authentication Service) with AMS (Authorization Management Service). This transition affects how trust relationships and token exchanges work at the BTP layer, though the S/4HANA backend authentication mechanisms remain stable. [src6]

| Property | Value |
|---|---|
| **Vendor** | SAP |
| **System** | SAP S/4HANA 2025 / Cloud 2H 2025 |
| **API Surface** | OData v2/v4, SOAP, RFC/BAPI |
| **Current Release** | 2025 FPS01 (Private Cloud), 2H 2025 (Public Cloud) |
| **Editions Covered** | Public Cloud, Private Cloud (RISE), On-Premise |
| **Deployment** | Cloud / On-Premise / Hybrid |
| **API Docs URL** | [SAP API Business Hub](https://api.sap.com/products/SAPS4HANACloud/overview) |
| **Status** | GA |

## API Surfaces & Capabilities

SAP S/4HANA exposes APIs through multiple surfaces. Each surface supports different authentication methods, and the intersection of API surface and deployment model determines which authentication flows are available.

| API Surface | Protocol | Auth Methods (Cloud) | Auth Methods (On-Prem) | Primary Use |
|---|---|---|---|---|
| OData v2/v4 | HTTPS/JSON+XML | OAuth 2.0, mTLS, Basic (deprecated) | Basic, X.509, OAuth 2.0, Kerberos | Standard API integration |
| SOAP | HTTPS/XML | OAuth 2.0, mTLS, Basic (deprecated) | Basic, X.509, Kerberos | Legacy integration, IDocs |
| RFC/BAPI | SNC/TCP | N/A (not exposed in Public Cloud) | SNC (X.509, Kerberos) | SAP-to-SAP, SAP GUI |
| SAP GUI | DIAG/SNC | N/A (not applicable) | Kerberos/SPNEGO, X.509/SNC, SAML | Interactive user access |
| Fiori/UI5 | HTTPS | SAML 2.0, IAS | SAML 2.0, Kerberos/SPNEGO | Browser-based UI access |

## Authentication Methods — Comprehensive Reference

### Method 1: OAuth 2.0 Client Credentials

The Client Credentials grant is used for system-to-system integration where no user context is needed. The calling system authenticates with its own client ID and client secret (or client certificate) to obtain an access token. [src1]

| Property | Value |
|---|---|
| **Grant Type** | `client_credentials` |
| **User Context** | None — runs as technical communication user |
| **Token Lifetime** | Configurable; default 12 hours (S/4HANA Cloud) |
| **Refresh Token** | Not applicable — request new token when expired |
| **Deployment** | Public Cloud, Private Cloud, On-Premise (via XSUAA/IAS) |
| **Security Level** | Standard (with client secret) / High (with client certificate) |
| **SAP Recommendation** | Preferred for server-to-server integrations without user context |

**When to use**: Scheduled batch jobs, middleware-to-S/4HANA integrations, monitoring scripts, data migration tools — any scenario where the calling system acts on its own behalf. [src3, src4]

### Method 2: OAuth 2.0 SAML Bearer Assertion

The SAML Bearer Assertion flow propagates a named user's identity from an external system through to S/4HANA. The calling system presents a signed SAML assertion to the OAuth token endpoint, which validates it and issues an access token scoped to the asserted user. [src7]

| Property | Value |
|---|---|
| **Grant Type** | `urn:ietf:params:oauth:grant-type:saml2-bearer` |
| **User Context** | Yes — access token is scoped to the propagated user |
| **Token Lifetime** | Configurable; default 12 hours |
| **Refresh Token** | Not supported |
| **Deployment** | Public Cloud, Private Cloud |
| **Security Level** | High — requires trust relationship + signed SAML assertion |
| **SAP Recommendation** | Preferred when user-level audit trail or authorization is required |

**When to use**: BTP extension apps calling back to S/4HANA on behalf of the logged-in user, Fiori launchpad integrations, any scenario requiring user-level authorization enforcement in S/4HANA. The SAML assertion is signed using the local service provider's private key, and S/4HANA must have the corresponding public certificate to verify the signature. [src1, src7]

### Method 3: X.509 Certificate / mTLS (ClientCertificateAuthentication)

Mutual TLS (mTLS) provides the strongest authentication by requiring the client to present a valid X.509 certificate during the TLS handshake. S/4HANA Cloud comes with a ready-to-use client default certificate. [src2]

| Property | Value |
|---|---|
| **Protocol** | TLS 1.2+ with client certificate |
| **User Context** | Technical communication user (mapped to certificate subject) |
| **Session** | Per-request — no token to manage |
| **Deployment** | All — Public Cloud, Private Cloud, On-Premise |
| **Security Level** | Highest — no credentials transmitted over the wire |
| **Certificate Requirements** | CA-signed (Cloud); CA-signed or self-signed (On-Premise) |

**When to use**: Highest-security integrations, regulated industries, environments that prohibit password-based authentication, or when combined with OAuth as the client authentication method (OAuth + mTLS). [src2, src4]

**Cloud-specific requirement**: S/4HANA Cloud Public Edition does not accept self-signed X.509 certificates. Your certificate must be signed by a Certificate Authority (CA) known to the S/4HANA Cloud backend. SAP provides a client default certificate that can be used directly. [src2]

### Method 4: Basic Authentication (Username/Password)

Basic Authentication transmits a base64-encoded username and password in the HTTP Authorization header. While simple to implement, it is deprecated for S/4HANA Cloud Public Edition and should only be used for development/testing. [src1, src4]

| Property | Value |
|---|---|
| **Protocol** | HTTP Basic (RFC 7617) |
| **User Context** | Technical communication user or named user |
| **Deployment** | On-Premise (supported), Private Cloud (limited), Public Cloud (deprecated) |
| **Security Level** | Low — credentials in every request (even with TLS) |
| **SAP Status** | Deprecated for S/4HANA Cloud Public Edition (2024+) |

**When to use**: Legacy on-premise integrations during migration to OAuth, development/testing environments only. Do not use for new production integrations on any deployment model. [src1]

### Method 5: SAML 2.0 (Browser SSO)

SAML 2.0 is used for browser-based single sign-on to SAP Fiori, Web GUI, and other web-based SAP applications. It is not used for API authentication directly but is critical for interactive user access. [src4]

| Property | Value |
|---|---|
| **Protocol** | SAML 2.0 (HTTP POST binding) |
| **User Context** | Named user (browser session) |
| **Deployment** | All deployment models |
| **IdP Support** | SAP IAS, Microsoft Entra ID (Azure AD), Okta, PingFederate, ADFS |
| **SAP Recommendation** | Standard for browser-based SSO across all deployment models |

**When to use**: Fiori launchpad access, SAP Web GUI, any browser-based SAP application. Configure in SAP IAS (Cloud) or SAML 2.0 trust configuration (on-premise transaction SAML2). [src1, src6]

### Method 6: Kerberos/SPNEGO + SNC

Kerberos with SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) provides transparent SSO for Windows domain users accessing SAP GUI and web applications. It uses Secure Network Communications (SNC) as the transport layer. [src5]

| Property | Value |
|---|---|
| **Protocol** | Kerberos 5 / SPNEGO over SNC |
| **User Context** | Named user (Windows domain identity) |
| **Deployment** | On-Premise only, Private Cloud (limited with Cloud Connector) |
| **Requires** | Active Directory, SAP Secure Login Server or SAP Single Sign-On, SNC configuration |
| **Not Available** | S/4HANA Cloud Public Edition |

**When to use**: On-premise environments with Active Directory where users need transparent SSO to SAP GUI for Windows and web applications. Users log in once to their Windows domain, and subsequent SAP access uses the Kerberos token. Requires mapping SNC user names (based on Windows domain identity) to SAP ABAP user names in SU01. [src5]

## Rate Limits & Quotas

Authentication itself is not rate-limited in SAP S/4HANA, but the APIs accessed after authentication are subject to fair-use throttling (Cloud) or dialog work process limits (on-premise).

### OAuth Token Endpoint Limits

| Limit Type | Value | Applies To | Notes |
|---|---|---|---|
| Token request rate | Fair use / not published | S/4HANA Cloud | Cache tokens — do not request a new token per API call |
| Token lifetime | 12h default (configurable) | S/4HANA Cloud | Configured in communication arrangement |
| Concurrent sessions per comm. user | No hard limit published | S/4HANA Cloud | Practical limit determined by system resources |
| Certificate validity | Max 2 years (Cloud) | S/4HANA Cloud mTLS | Plan certificate rotation well before expiry |

[src1, src3]

### Communication Arrangement Limits

| Limit Type | Value | Applies To | Notes |
|---|---|---|---|
| Max communication arrangements | No hard limit | S/4HANA Cloud | One per integration scenario per external system |
| Auth methods per arrangement | 1 primary | S/4HANA Cloud | Cannot mix OAuth and Basic in same arrangement |
| Communication users per system | Multiple allowed | S/4HANA Cloud | Each can have different auth methods |
| Inbound scenarios per arrangement | Multiple services | S/4HANA Cloud | Grouped by communication scenario |

[src1]

## Authentication

### Authentication by Deployment Model — Decision Matrix

| Auth Method | Public Cloud | Private Cloud | On-Premise | User Context | Security Level |
|---|---|---|---|---|---|
| OAuth 2.0 Client Credentials | Yes | Yes | Yes (with XSUAA/IAS) | No | Standard/High |
| OAuth 2.0 SAML Bearer | Yes | Yes | Possible (with BTP) | Yes | High |
| X.509 / mTLS | Yes | Yes | Yes (SNC) | No | Highest |
| Basic Auth | Deprecated | Limited | Yes | Varies | Low |
| SAML 2.0 (Browser SSO) | Yes | Yes | Yes | Yes | High |
| Kerberos/SPNEGO | No | Limited | Yes | Yes | High |

[src1, src2, src4, src5]

### Authentication Gotchas

- **OAuth token caching is critical**: SAP does not publish explicit rate limits on the token endpoint, but requesting a new token for every API call is an anti-pattern that can trigger throttling. Cache tokens and reuse them until near expiry. [src3]
- **Communication user vs. named user confusion**: In S/4HANA Cloud, a "Communication User" is a technical user for system-to-system integration (cannot log in interactively). A "Business User" is a named user with dialog access. Using the wrong user type causes authentication failures with unhelpful error messages. [src1]
- **Principal propagation requires end-to-end trust chain**: For SAML Bearer Assertion to work, trust must be configured between the IdP (e.g., SAP IAS), the calling application (BTP app), and the S/4HANA backend. Missing any link in the chain causes silent authentication failures. [src7]
- **XSUAA-to-IAS migration timeline**: SAP is strategically migrating from XSUAA to IAS for authentication. New BTP applications should use IAS from the start. Existing XSUAA-based apps remain supported, but plan for migration. SuccessFactors has a hard deadline of November 2026. [src6]
- **SNC name mapping is case-sensitive**: When configuring Kerberos/SPNEGO, the SNC name in SU01 must exactly match the format produced by the Kerberos token — including case. Mismatches cause "SNC name mismatch" errors that are difficult to diagnose. [src5]

## Constraints
<!-- Agents: read this section before recommending any integration approach from this unit.
     These are hard constraints that must not be violated. -->

- **Basic Auth deprecated on Public Cloud**: Any new inbound integration to S/4HANA Cloud Public Edition must use OAuth 2.0 or mTLS. Existing Basic Auth integrations should be migrated. [src1]
- **No Authorization Code or Implicit OAuth flows**: S/4HANA Cloud only supports Client Credentials and SAML Bearer Assertion grant types for API access. Do not attempt Authorization Code flows directly against S/4HANA. [src1]
- **Self-signed certificates rejected on Cloud**: S/4HANA Cloud Public Edition requires CA-signed X.509 certificates. Self-signed certificates work only on on-premise systems. [src2]
- **Kerberos/SPNEGO not available on Public Cloud**: This authentication method requires SAP Secure Login Server and Active Directory integration, which is only possible on-premise or with Cloud Connector for Private Cloud. [src5]
- **Communication arrangements are per-scenario**: Each communication arrangement binds one authentication method to one set of API services. You cannot use different auth methods for different APIs within the same arrangement. [src1]
- **IAS migration in progress**: SAP's strategic direction is IAS + AMS. XSUAA remains supported but is legacy. Plan architecture decisions accordingly. [src6]

## Integration Pattern Decision Tree

```
START — User needs to authenticate against SAP S/4HANA
├── What deployment model?
│   ├── Public Cloud
│   │   ├── System-to-system (no user context)?
│   │   │   ├── Standard security → OAuth 2.0 Client Credentials (client secret)
│   │   │   └── High security → OAuth 2.0 Client Credentials (mTLS client auth)
│   │   │       OR → X.509 ClientCertificateAuthentication (direct mTLS)
│   │   ├── User context needed (principal propagation)?
│   │   │   └── OAuth 2.0 SAML Bearer Assertion
│   │   │       (requires IdP trust: SAP IAS or third-party SAML IdP)
│   │   └── Browser SSO?
│   │       └── SAML 2.0 via SAP IAS (or federated third-party IdP)
│   ├── Private Cloud (RISE)
│   │   ├── Same as Public Cloud options, PLUS:
│   │   ├── Cloud Connector available?
│   │   │   ├── YES → Principal propagation via Cloud Connector (technical or named user)
│   │   │   └── NO → OAuth 2.0 flows only
│   │   └── Kerberos needed?
│   │       └── Possible via Cloud Connector + on-premise AD, but complex
│   └── On-Premise
│       ├── SAP GUI access?
│       │   ├── Windows domain users → Kerberos/SPNEGO via SNC
│       │   ├── External users → X.509 certificates via SNC
│       │   └── Legacy → Basic Auth (plan migration)
│       ├── API access (OData/SOAP)?
│       │   ├── Standard → Basic Auth (still supported on-prem)
│       │   ├── Modern → OAuth 2.0 via XSUAA/IAS on BTP
│       │   └── High security → X.509 / mTLS
│       └── Browser SSO (Fiori)?
│           ├── Internal users → Kerberos/SPNEGO
│           └── External users → SAML 2.0
└── What security level?
    ├── Standard → OAuth 2.0 Client Credentials with client secret
    ├── High → OAuth 2.0 with mTLS client auth, or direct mTLS
    └── Enterprise → SAML federation + principal propagation
```

## Quick Reference

### Authentication Method Selection Matrix

| Scenario | Recommended Auth | Deployment | Setup Complexity | Notes |
|---|---|---|---|---|
| Middleware reads S/4HANA data (batch) | OAuth 2.0 Client Credentials | All Cloud | Low | Communication arrangement + OAuth client |
| BTP app calls S/4HANA as logged-in user | OAuth 2.0 SAML Bearer | Public/Private Cloud | Medium | Requires IAS trust + destination config |
| iPaaS platform (MuleSoft, Workato) | OAuth 2.0 Client Credentials | All Cloud | Low | Most iPaaS platforms support this natively |
| SAP-to-SAP (CPI/Integration Suite) | OAuth 2.0 Client Credentials | Private Cloud | Low-Medium | Pre-configured in Integration Suite |
| Regulated industry (banking, pharma) | X.509 / mTLS | All | Medium-High | CA-signed cert required on Cloud |
| On-prem SAP GUI transparent SSO | Kerberos/SPNEGO + SNC | On-Premise | High | Requires AD + SAP Secure Login Server |
| Fiori browser SSO | SAML 2.0 | All | Medium | IAS (Cloud) or SAML2 transaction (on-prem) |
| Legacy third-party integration | Basic Auth | On-Premise only | Low | Deprecated on Cloud — plan migration |
| DevOps / CI-CD pipeline | OAuth 2.0 Client Credentials | All Cloud | Low | Token caching essential |
| Webhook / event receiver | OAuth 2.0 Client Credentials | All Cloud | Low | S/4HANA outbound to external system |

[src1, src3, src4]

## Step-by-Step Integration Guide

### 1. Set Up OAuth 2.0 Client Credentials (S/4HANA Cloud Public Edition)

Create a communication arrangement in S/4HANA Cloud that exposes the required API services and generates OAuth credentials. [src1]

```
Step 1: In S/4HANA Cloud, go to "Communication Arrangements" (Fiori app)
Step 2: Click "New" → select the Communication Scenario (e.g., SAP_COM_0008 for Business Partner)
Step 3: Create or assign a Communication System (represents the external caller)
Step 4: Create a Communication User:
        - Authentication Method: OAuth 2.0
        - Grant Type: Client Credentials
        - Download or note the Client ID and Client Secret
Step 5: Save the arrangement — note the Token Endpoint URL:
        https://{tenant}.s4hana.cloud.sap/sap/bc/sec/oauth2/token
```

**Verify**: Request a token using the credentials:

```bash
# Input:  Client ID, Client Secret, Token Endpoint URL
# Output: JSON with access_token, token_type, expires_in

curl -X POST "https://{tenant}.s4hana.cloud.sap/sap/bc/sec/oauth2/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -u "{client_id}:{client_secret}" \
  -d "grant_type=client_credentials"
```

**Verify**: Response contains `"access_token"` and `"token_type": "bearer"` [src1, src3]

### 2. Use the Access Token to Call an OData API

Once you have a valid access token, include it in the Authorization header of your API request. [src4]

```bash
# Input:  Access token from Step 1, OData service URL
# Output: OData JSON response with business data

curl -X GET "https://{tenant}.s4hana.cloud.sap/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner?$top=10" \
  -H "Authorization: Bearer {access_token}" \
  -H "Accept: application/json"
```

**Verify**: HTTP 200 with `d.results` array containing business partner data [src4]

### 3. Set Up mTLS / X.509 Certificate Authentication (S/4HANA Cloud)

For highest-security environments, configure certificate-based authentication in the communication arrangement. [src2]

```
Step 1: Obtain a CA-signed X.509 client certificate (PEM or PKCS#12 format)
        — SAP Cloud provides a "client default certificate" you can use directly
Step 2: In "Communication Arrangements", create/edit the arrangement
Step 3: For the Communication User, select Authentication Method:
        "SSL Client Certificate"
Step 4: Upload the client certificate's public key to the Communication User
Step 5: Map the certificate's Subject DN to the communication user
Step 6: Save — the system now accepts mTLS connections using this certificate
```

**Verify**: Call the API using the client certificate:

```bash
# Input:  Client certificate (PEM), private key, API endpoint
# Output: OData JSON response (same as OAuth, but no token exchange needed)

curl -X GET "https://{tenant}.s4hana.cloud.sap/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner?$top=5" \
  --cert client-cert.pem \
  --key client-key.pem \
  -H "Accept: application/json"
```

**Verify**: HTTP 200 — certificate was accepted and user was mapped correctly [src2]

### 4. Configure SAML 2.0 Browser SSO (All Deployment Models)

Set up SAML-based single sign-on for Fiori and web application access. [src1]

```
For S/4HANA Cloud (Public/Private):
  Step 1: Configure SAP IAS as the Identity Provider (or federate to your corporate IdP)
  Step 2: In S/4HANA Cloud admin, navigate to "Trust Configuration"
  Step 3: Download the S/4HANA SAML metadata (Service Provider metadata)
  Step 4: Upload SP metadata to your IdP (SAP IAS, Entra ID, Okta, etc.)
  Step 5: Upload IdP metadata to S/4HANA Cloud trust configuration
  Step 6: Map IdP user attributes to S/4HANA business user attributes (email, user ID)

For On-Premise:
  Step 1: Run transaction SAML2 to configure S/4HANA as SAML Service Provider
  Step 2: Exchange metadata with your IdP
  Step 3: Configure name ID mapping and attribute assertions
  Step 4: Enable SAML authentication in ICF service nodes
```

**Verify**: Access Fiori launchpad URL in browser — should redirect to IdP login, then return authenticated [src1]

## Code Examples

### Python: OAuth 2.0 Client Credentials Token Acquisition and API Call

```python
# Input:  S/4HANA Cloud tenant URL, OAuth client ID and secret
# Output: Business Partner data as JSON

import requests  # requests==2.31.0

# Configuration
TENANT_URL = "https://{tenant}.s4hana.cloud.sap"
TOKEN_URL = f"{TENANT_URL}/sap/bc/sec/oauth2/token"
CLIENT_ID = "your_client_id"
CLIENT_SECRET = "your_client_secret"

# Step 1: Obtain access token
token_response = requests.post(
    TOKEN_URL,
    auth=(CLIENT_ID, CLIENT_SECRET),
    data={"grant_type": "client_credentials"},
    headers={"Content-Type": "application/x-www-form-urlencoded"},
)
token_response.raise_for_status()
access_token = token_response.json()["access_token"]

# Step 2: Call OData API with bearer token
api_url = f"{TENANT_URL}/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner"
api_response = requests.get(
    api_url,
    headers={
        "Authorization": f"Bearer {access_token}",
        "Accept": "application/json",
    },
    params={"$top": 10, "$select": "BusinessPartner,BusinessPartnerFullName"},
)
api_response.raise_for_status()
partners = api_response.json()["d"]["results"]
for bp in partners:
    print(f"{bp['BusinessPartner']}: {bp['BusinessPartnerFullName']}")
```

### Python: mTLS Certificate-Based Authentication

```python
# Input:  S/4HANA Cloud tenant URL, client certificate and key files (PEM)
# Output: Business Partner data as JSON — no OAuth token exchange needed

import requests  # requests==2.31.0

TENANT_URL = "https://{tenant}.s4hana.cloud.sap"
CERT_FILE = "client-cert.pem"   # CA-signed X.509 certificate
KEY_FILE = "client-key.pem"     # Private key

api_url = f"{TENANT_URL}/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner"
response = requests.get(
    api_url,
    cert=(CERT_FILE, KEY_FILE),  # mTLS: client presents certificate
    headers={"Accept": "application/json"},
    params={"$top": 5},
)
response.raise_for_status()
print(response.json()["d"]["results"])
```

### cURL: Test OAuth Token Endpoint

```bash
# Input:  Client ID, Client Secret, Token endpoint URL
# Output: JSON with access_token, token_type, expires_in

# Request token
curl -s -X POST "https://{tenant}.s4hana.cloud.sap/sap/bc/sec/oauth2/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -u "{client_id}:{client_secret}" \
  -d "grant_type=client_credentials" | python -m json.tool

# Expected response shape:
# {
#   "access_token": "eyJ...",
#   "token_type": "bearer",
#   "expires_in": 43200
# }
```

## Data Mapping

### Authentication Configuration Mapping

| Configuration Item | Public Cloud Location | Private Cloud Location | On-Premise Location |
|---|---|---|---|
| Communication Arrangement | Fiori: "Communication Arrangements" app | Fiori: "Communication Arrangements" app | N/A (use SM59 / SOAMANAGER) |
| OAuth Client Registration | Auto-generated in comm. arrangement | Auto-generated in comm. arrangement | Transaction SOAUTH2 or BTP XSUAA |
| X.509 Certificate Upload | Communication User settings | Communication User settings | Transaction STRUST (PSE management) |
| SAML Trust Configuration | Administration > Trust Configuration | Administration > Trust Configuration | Transaction SAML2 |
| Kerberos/SNC Config | N/A | Cloud Connector + SNC | Transaction RZ10 (profile params) + SU01 (SNC name) |
| IdP Metadata Exchange | SAP IAS admin console | SAP IAS admin console | Transaction SAML2 (metadata upload) |

[src1, src5]

### Data Type Gotchas

- **Communication User IDs in S/4HANA Cloud are UUIDs, not readable names**: Unlike on-premise where you choose a user ID like RFC_USER, Cloud communication users get system-generated IDs. Use the communication arrangement name for identification. [src1]
- **OAuth client secrets cannot be retrieved after creation**: If you lose the client secret, you must generate a new one in the communication arrangement. Store secrets securely in a vault immediately after creation. [src1]
- **SNC names follow different formats depending on provider**: Kerberos SNC names use format `p:CN=user@DOMAIN.COM` while X.509 SNC names use `p:CN=Common Name, O=Org, C=Country`. Mixing formats causes mapping failures. [src5]

## Error Handling & Failure Points

### Common Error Codes

| HTTP Code / Error | Meaning | Cause | Resolution |
|---|---|---|---|
| 401 Unauthorized | Authentication failed | Invalid credentials, expired token, certificate not trusted | Verify credentials; check token expiry; ensure CA cert is in trust store |
| 403 Forbidden | Authenticated but not authorized | Communication user lacks authorization for the requested API service | Check communication arrangement scope; verify business catalog assignments |
| 400 Bad Request (OAuth) | Token request malformed | Wrong grant_type, missing parameters, wrong Content-Type header | Use `application/x-www-form-urlencoded`; verify grant_type string exactly |
| SSL Handshake Failure | mTLS certificate rejected | Self-signed cert on Cloud, expired cert, wrong CA chain | Use CA-signed cert on Cloud; verify cert chain; check expiry dates |
| SAML Assertion Invalid | SAML bearer token rejected | Assertion expired, signature verification failed, issuer not trusted | Check clock sync; verify signing cert in trust config; check SAML issuer ID |
| SNC Name Mismatch | Kerberos auth failed | SNC name in SU01 does not match Kerberos principal | Verify exact SNC name format and case in SU01; run SNC diagnostic trace |

[src1, src2, src5]

### Failure Points in Production

- **Token expiry not handled gracefully**: Integration stops working silently when cached OAuth tokens expire and the renewal logic has a bug. Fix: `Implement token refresh 5 minutes before expiry; add retry-on-401 logic that requests a fresh token and replays the failed request`. [src3]
- **Certificate rotation causes outage**: X.509 certificates expire after 1-2 years. If the new certificate is not uploaded to the communication user before the old one expires, all mTLS connections fail immediately. Fix: `Set calendar reminder 30 days before expiry; upload new cert while old is still valid (both can be active); test with new cert before deactivating old`. [src2]
- **Communication arrangement deleted accidentally**: Deleting a communication arrangement revokes all associated OAuth credentials instantly. Fix: `Implement naming conventions and documentation for all arrangements; use S/4HANA Cloud change management to prevent accidental deletion`. [src1]
- **Principal propagation fails after IdP certificate rotation**: When the SAML IdP rotates its signing certificate, the trust relationship in S/4HANA breaks because it still has the old certificate. Fix: `Upload new IdP certificate to S/4HANA trust configuration before the IdP starts using it; keep old cert active during transition period`. [src7]
- **Clock skew breaks SAML assertions**: SAML assertions have NotBefore and NotOnOrAfter timestamps. If the S/4HANA system clock is off by more than a few minutes, valid assertions are rejected. Fix: `Ensure NTP synchronization on all systems; check SAML assertion validity window (typically 5-10 minutes)`. [src7]

## Anti-Patterns

### Wrong: Requesting a new OAuth token for every API call

```python
# BAD — hammers the token endpoint, may trigger throttling
for record in records:
    token = get_new_oauth_token()  # New token per request!
    call_api(token, record)
```

### Correct: Cache and reuse the OAuth token

```python
# GOOD — token cached, refreshed only when near expiry
import time

class TokenCache:
    def __init__(self, client_id, client_secret, token_url):
        self._token = None
        self._expiry = 0
        self._client_id = client_id
        self._client_secret = client_secret
        self._token_url = token_url

    def get_token(self):
        if self._token and time.time() < self._expiry - 300:  # 5min buffer
            return self._token
        resp = requests.post(self._token_url,
            auth=(self._client_id, self._client_secret),
            data={"grant_type": "client_credentials"})
        data = resp.json()
        self._token = data["access_token"]
        self._expiry = time.time() + data["expires_in"]
        return self._token
```

### Wrong: Using Basic Auth for new Cloud integrations

```
# BAD — Basic Auth is deprecated on S/4HANA Cloud Public Edition
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
```

### Correct: Use OAuth 2.0 Client Credentials

```
# GOOD — OAuth 2.0 is the standard for S/4HANA Cloud
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
```

### Wrong: Storing OAuth client secrets in source code

```python
# BAD — secrets in code are visible in version control
CLIENT_SECRET = "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
```

### Correct: Use environment variables or a secrets manager

```python
# GOOD — secrets from environment or vault
import os
CLIENT_SECRET = os.environ["SAP_OAUTH_CLIENT_SECRET"]
# Or use a secrets manager (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault)
```

## Common Pitfalls

- **Confusing BTP authentication with S/4HANA backend authentication**: BTP uses XSUAA/IAS for its own services. S/4HANA Cloud uses its own OAuth implementation via communication arrangements. When integrating a BTP app with S/4HANA, you need both layers configured — BTP destination with the S/4HANA OAuth credentials. Fix: `Configure BTP Destination service with S/4HANA token endpoint, client ID, and client secret; set "Authentication" to "OAuth2ClientCredentials" or "OAuth2SAMLBearerAssertion"`. [src6]
- **Not mapping communication users to business roles**: Creating a communication user in S/4HANA Cloud does not automatically grant API access. The communication arrangement must include the correct communication scenarios, which are tied to business catalogs and roles. Fix: `Verify the communication scenario includes the OData/SOAP services you need; check that the communication user's assigned communication system has the right scope`. [src1]
- **Ignoring SAP's XSUAA-to-IAS migration**: Building new integrations on XSUAA when SAP's strategic direction is IAS creates technical debt. Fix: `For new applications, use SAP IAS from the start. For existing apps, plan migration using hybrid authentication mode (accepts both XSUAA and IAS tokens during transition)`. [src6]
- **Certificate chain incomplete on Cloud**: Uploading only the client certificate without the intermediate CA certificates causes SSL handshake failures on S/4HANA Cloud. The system needs the full chain to verify trust. Fix: `Export the full certificate chain (client cert + intermediate CAs) in PEM format and upload all certificates to the communication user's trusted CAs`. [src2]

## Diagnostic Commands

```bash
# Test OAuth 2.0 token endpoint (Client Credentials)
curl -v -X POST "https://{tenant}.s4hana.cloud.sap/sap/bc/sec/oauth2/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -u "{client_id}:{client_secret}" \
  -d "grant_type=client_credentials"
# Expected: HTTP 200 with access_token in JSON body
# If 401: client_id or client_secret is wrong
# If 400: grant_type or Content-Type is wrong

# Test mTLS certificate authentication
curl -v --cert client-cert.pem --key client-key.pem \
  "https://{tenant}.s4hana.cloud.sap/sap/opu/odata/sap/API_BUSINESS_PARTNER/$metadata"
# Expected: HTTP 200 with OData metadata XML
# If SSL handshake error: certificate not trusted (check CA chain)

# Verify OAuth token validity (decode JWT)
echo "{access_token}" | cut -d. -f2 | base64 -d 2>/dev/null | python -m json.tool
# Check: "exp" (expiry timestamp), "client_id", "scope"

# Test S/4HANA Cloud API with bearer token
curl -s -o /dev/null -w "%{http_code}" \
  -H "Authorization: Bearer {access_token}" \
  "https://{tenant}.s4hana.cloud.sap/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner?$top=1"
# Expected: 200
# If 401: token expired or invalid
# If 403: communication user lacks authorization for this service

# Check SAML metadata (on-premise)
# Transaction SAML2 > "Local Provider" tab > "Metadata" > "Download Metadata"
# Verify: EntityID, signing certificate, supported bindings

# Verify SNC configuration (on-premise)
# Transaction RZ10 > Instance profile > Check parameters:
#   snc/enable = 1
#   snc/identity/as = p:CN=SID, O=SAP, C=DE
#   snc/accept_insecure_gui = 0 (production)
```

## Version History & Compatibility

| S/4HANA Version | Release | Auth Changes | Migration Notes |
|---|---|---|---|
| 2H 2025 (Cloud) | 2025-10 | OAuth Authorization Code with PKCE (RFC 7636) added; JWT-based client auth (RFC 7523) | New options for BTP integration; existing flows unaffected |
| 2025 FPS01 (Private Cloud) | 2025-08 | SAP-managed client certificates for Private Cloud | Simplifies mTLS setup for RISE customers |
| 2H 2024 (Cloud) | 2024-10 | Basic Auth formally deprecated for inbound APIs | Migrate to OAuth or mTLS; existing Basic Auth still works but unsupported |
| 2023 (On-Premise) | 2023-10 | No breaking changes | OAuth available via BTP; native auth methods unchanged |

[src1, src3]

### Deprecation Policy

SAP follows a two-release deprecation notice policy for S/4HANA Cloud. Authentication method changes are announced at least one release (6 months) before enforcement. On-premise customers have longer migration windows because they control their upgrade timeline. Basic Auth deprecation was announced in 2024 with no hard enforcement date yet, but SAP recommends immediate migration. [src1]

## When to Use / When Not to Use

| Use When | Don't Use When | Use Instead |
|---|---|---|
| System-to-system batch integration (no user context) | You need user-level audit trail in S/4HANA | OAuth 2.0 SAML Bearer Assertion (principal propagation) |
| S/4HANA Cloud Public Edition new integration | On-premise S/4HANA with existing Basic Auth | Basic Auth (on-prem only, plan migration) |
| Regulated industry requiring certificate-based auth | Simple dev/test environment | OAuth 2.0 Client Credentials (simpler setup) |
| Browser SSO for Fiori applications | API-to-API integration (no browser) | OAuth 2.0 Client Credentials or mTLS |
| Windows domain users accessing SAP GUI (on-prem) | Cloud deployment without Active Directory | SAML 2.0 browser SSO |

## Cross-System Comparison

| Capability | SAP S/4HANA Cloud | Oracle ERP Cloud | Salesforce | Microsoft Dynamics 365 |
|---|---|---|---|---|
| OAuth 2.0 | Client Credentials + SAML Bearer | Client Credentials + JWT Bearer | JWT Bearer + Web Server + Client Credentials | Client Credentials + Auth Code |
| Certificate Auth (mTLS) | Yes (CA-signed required) | Yes | Yes (connected app) | Yes (certificate-based) |
| Basic Auth | Deprecated (Cloud) | Not recommended | Not available (Cloud) | Supported |
| SAML SSO | SAML 2.0 via IAS | SAML 2.0 via OCI IAM | SAML 2.0 | SAML 2.0 via Entra ID |
| Kerberos/SPNEGO | On-premise only | Not applicable | Not applicable | Via Entra ID |
| API Key | Not supported | Not supported | Not supported (use OAuth) | Not supported |
| Token Lifetime | 12h default (configurable) | 1h (configurable) | 2h (session-based) | 1h default |
| IdP Flexibility | SAP IAS, any SAML 2.0 IdP | OCI IAM, any SAML 2.0 IdP | Any SAML/OIDC IdP | Entra ID (native), any SAML IdP |

## Important Caveats

- **Deployment model determines everything**: The same authentication method may work on on-premise but be completely unavailable on Public Cloud. Always verify against the specific deployment model before recommending an approach. [src1]
- **SAP's identity strategy is in transition**: The shift from XSUAA to IAS is ongoing. Documentation may reference both, and some BTP services still require XSUAA. Check current compatibility before choosing an identity provider layer. [src6]
- **Communication arrangement limits vary by S/4HANA Cloud release**: SAP enhances communication management with each release (e.g., Communication Targets in 2H 2025). Features described here may not be available on older releases. [src1]
- **This card covers authentication, not authorization**: Having a valid token does not mean the integration user has permission to access specific business data. Authorization (business roles, catalogs, restrictions) is a separate configuration layer that must also be set up correctly.
- **Rate limits on authentication endpoints are not published**: SAP uses fair-use policies for token endpoints. The absence of documented limits does not mean unlimited requests — always implement token caching and exponential backoff. [src3]

## Related Units

- [SAP S/4HANA OData API Capabilities](/business/erp-integration/sap-s4hana-odata-api/2026)
- [SAP BTP Security (XSUAA/IAS)](/business/erp-integration/sap-btp-security/2026)
- [SAP S/4HANA Authorization Model](/business/erp-integration/sap-authorization-model/2026)