Understanding SAP Authentication: SSO SNC and OAuth Security

SAP Authentication Architecture Overview

SAP systems support multiple authentication mechanisms simultaneously, creating a complex trust landscape that must be carefully managed. The three primary methods—SNC, SSO (including Logon Tickets and SAML), and OAuth 2.0—serve different purposes but share a common risk: any single compromised credential or misconfigured channel can grant an attacker system-level access.

Authentication in SAP operates at the system level (RFC gateway, dialog instance) and the application level (BTP services, Fiori apps). Each layer has its own security properties, and the gaps between them are where most breaches occur.

SAP Login and Access Control Flow

When a user authenticates to an SAP system, the request passes through several security boundaries: network transport (SNC), system logon (SAPGUI or RFC), and application authorization (roles and profiles). Each boundary can be enforced using different protocols, but they must work together coherently. A robust authentication strategy ensures that even if one layer is compromised, the others contain the damage.

For enterprises running ECC or S/4HANA, the most common authentication stack includes SNC for encrypted RFC connections, SAP Logon Tickets for SSO across SAPGUI sessions, and OAuth 2.0 for cloud integrations. Misconfigurations in any of these layers can open the door to what security teams call "SAP privilege escalation via authentication bypass."

Secure Network Communications (SNC) Security

SNC is SAP's implementation of the Generic Security Service Application Program Interface (GSS-API), providing encryption, integrity, and mutual authentication for all SAP communication layers. SNC works by wrapping standard SAP protocols (DIAG, RFC) in a cryptographic envelope, ensuring that data transmitted between SAP components—including between Application Servers, between the Central Instance and dialog instances, and between SAP and external RFC consumers—remains confidential and tamper-proof.

SNC Authentication Mechanisms

SNC supports multiple underlying security products, with the most common being Kerberos (Microsoft Active Directory) and X.509 certificates (via SAP Cryptographic Library or CommonCryptoLib). The choice of SNC mechanism directly impacts your authentication security posture:

• Kerberos-based SNC: Provides seamless integration with Windows Active Directory. The SAP system trusts the Kerberos ticket issued by the domain controller. Best for environments where users already authenticate via AD. However, Kerberos tickets can be stolen via Kerberoasting attacks if not properly hardened with AES encryption and ticket lifetime policies.
• X.509 certificate-based SNC: Uses public key infrastructure (PKI) certificates for authentication. More flexible than Kerberos for cross-domain or DMZ scenarios. Requires robust certificate lifecycle management—expired or revoked certificates can lock users out or create audit gaps.
• SNC with CommonCryptoLib (SAP's recommended library): Replaces older libraries (SAPCRYPTOLIB) and supports both Kerberos and certificate modes. Provides FIPS 140-2 validated encryption.

Critical SNC Configuration Parameters

Securing SNC goes beyond simply enabling it. Several parameters in the SAP profile determine whether SNC actually protects your system or just provides a false sense of security:

Common SNC Security Gaps

Even with SNC enabled, many SAP landscapes have exploitable gaps. The most frequent issues include:

• SNC not enforced for all connections: Many organizations enable SNC only for dialog (SAPGUI) users but leave RFC interfaces unprotected. Attackers can use unprotected RFC destinations to bypass SNC entirely.
• Weak SNC libraries: Using outdated SAPCRYPTOLIB instead of CommonCryptoLib introduces known vulnerabilities such as CVE-2018-7987 (buffer overflow in SNC negotiation).
• Lack of SNC for CPIC and external programs: Parameters like "accept_insecure_cpic" set to 1 allow third-party integrations to connect without SNC, creating a backdoor.
• No SNC for system-to-system RFC: Internal RFC connections between SAP systems (e.g., ALE, idocs) often bypass SNC, leaving data in transit exposed within the network.

CyberSilo SAP Guardian includes automated SNC configuration auditing that detects these gaps against SAP's security baseline recommendations, alerting your Basis team before an attacker exploits them.

SSO: SAP Logon Tickets and SAML

Single Sign-On (SSO) reduces password fatigue and credential exposure, but introduces its own trust relationships. SAP supports two primary SSO mechanisms: SAP Logon Tickets (for traditional SAPGUI and web access) and SAML 2.0 (for web-based and cloud applications). Both require careful security configuration to prevent ticket forgery, replay attacks, and unauthorized delegation.

SAP Logon Ticket Security

SAP Logon Tickets (also called SAP Logon Tokens) are digitally signed cookies issued by an SAP system acting as a ticket issuer. The ticket contains the user ID, a validity period, and the issuer's signature. Any SAP system that trusts the issuer's public key can accept the ticket for authentication.

Key security considerations for Logon Tickets:

• Ticket lifetime: Default is 480 minutes (8 hours). Longer lifetimes increase the window for token theft and replay. Limit to 60–120 minutes for high-security environments.
• Ticket signing certificate: Must use a strong key length (2048-bit RSA minimum). Some older installations still use 1024-bit keys, which are now considered breakable.
• Ticket scope: The ticket should not include the "user_alias" field unless necessary, as this enables delegation and increases the attack surface.
• Trust configuration: The table TRUSTED_SYSTEMS must be strictly limited to systems that genuinely need to accept tickets. Each entry is an attack vector if compromised.

SAML 2.0 Authentication for SAP

SAML 2.0 is the standard for web-based SSO in SAP Fiori, SAP Cloud Platform, and SAP BTP. In a typical SAML flow, the user authenticates to an Identity Provider (IdP) such as Azure AD, Okta, or SAP Cloud Identity Services, which then issues a SAML assertion that the SAP system (Service Provider) validates.

Critical SAML security controls:

• Assertion encryption: SAP systems must require encrypted assertions. Unencrypted assertions can be intercepted and replayed.
• Assertion lifetime: Short-lived assertions (5–10 minutes) reduce the window for replay attacks. The NotOnOrAfter condition should be strictly enforced.
• Audience restriction: The SAML assertion must include the exact entity ID of the target SAP system. Without this restriction, an attacker can use a SAML token issued for one SAP system to access another.
• Certificate validation: The IdP signing certificate must be properly imported into the SAP system's certificate store (STRUST). Expired or self-signed certificates create validation gaps.

OAuth 2.0 and OpenID Connect for SAP BTP

As organizations migrate to SAP Business Technology Platform (BTP) and cloud-integrated S/4HANA, OAuth 2.0 has become the primary authentication protocol for API access, service-to-service communication, and mobile app integration. OAuth 2.0 is not an authentication protocol by itself—it is an authorization framework—so it is almost always used with OpenID Connect (OIDC) for identity verification.

OAuth Flow Types and Security Implications

SAP BTP supports multiple OAuth 2.0 grant types. Each grant type has different security properties and attack surfaces:

OAuth Token Security Risks

OAuth tokens in SAP BTP environments present several unique security challenges:

• Token leakage via redirect URIs: If your application registers too-permissive redirect URIs (e.g., using wildcards), an attacker can intercept the authorization code and exchange it for an access token.
• Scope escalation: SAP BTP tokens can carry scopes like "uaa.resource" or "openid." Misconfigured scopes grant broader access than intended. The principle of least privilege must be enforced at the token level, not just at the application level.
• Token storage in SAP systems: When BTP services store OAuth tokens in SAP HANA or S/4HANA tables for offline scenarios, those tokens must be encrypted at rest. Several SAP incidents have involved tokens extracted from unencrypted database columns.
• Refresh token lifetime: Refresh tokens with no expiration create permanent access for any client that obtains one. SAP BTP allows configuring refresh token validity; set it to the shortest practical duration for your architecture.

Authentication Audit and Monitoring

No authentication architecture is secure without visibility into how it is being used. SAP provides several logging mechanisms—security audit log (SM19/SM20), RFC audit log (SRFC_ADMIN), and the new SAP Audit Layer for BTP—but these logs are notoriously fragmented and complex to correlate.

Effective authentication monitoring requires:

• Centralized logging of ALL authentication events: SNC failures, logon ticket creation, SAML assertion validation, and OAuth token issuance must feed into a single security monitoring platform. Without this correlation, a threat actor can pivot between authentication methods without triggering an alert.
• Anomaly detection on authentication patterns: Users authenticating from unexpected locations, at unusual times, or via different protocols simultaneously (e.g., SNC + OAuth) indicate credential theft.
• Integration with identity governance: Authentication monitoring must be linked with your SAP GRC system to detect when an authenticated user attempts actions that violate segregation-of-duties rules.

CyberSilo SAP Guardian aggregates authentication logs across SNC, Logon Tickets, SAML, and OAuth into a single monitoring view, applying behavioral analytics to detect anomalous patterns before they become breaches. The platform correlates authentication events with authorization activity, providing a complete picture of who accessed what—and whether they should have been allowed to.

Implementing a Layered Authentication Security Strategy

A robust SAP authentication strategy follows the defense-in-depth principle, ensuring that no single misconfiguration can be exploited to compromise the entire system. The following phased approach helps organizations systematically harden their authentication layers.

Authentication Threat Vectors and Mitigations

Understanding how attackers exploit authentication weaknesses helps prioritize hardening efforts. Below are the most common attack patterns targeting SAP authentication.

SNC Impersonation and Bypass Attacks

Attackers can exploit SNC misconfigurations in several ways:

• SNC downgrade attack: If snc/permit_insecure_start is set to 1, an attacker can force the connection to fall back to unencrypted communication, then intercept credentials or manipulate data in transit.
• Kerberos ticket theft: Using tools like Mimikatz, attackers can extract Kerberos tickets from user workstations and replay them against the SAP system if SNC uses Kerberos and the ticket is not properly bound to the client machine.
• Certificate spoofing: If the SAP system does not properly validate the full certificate chain in X.509 SNC mode, an attacker can present a self-signed certificate and gain authentication.

SAML Assertion Forgery and Replay

SAML attacks have become more sophisticated as cloud adoption increases:

• XML signature wrapping: An attacker intercepts a valid SAML assertion and modifies the XML structure while preserving the digital signature. SAP systems that validate signatures using older libraries may accept these manipulated assertions.
• Assertion replay: If the SAP system does not check the NotOnOrAfter condition or does not maintain a cache of previously used assertion IDs, an attacker can capture and reuse a valid assertion multiple times.
• IdP spoofing: If the SAP system trusts multiple IdPs, an attacker can set up a rogue IdP that issues assertions for any user, then trick the SAP system into accepting them.

OAuth Token Interception and Escrow

OAuth-specific attacks in BTP environments include:

• Authorization code interception: Attackers can exploit open redirectors in your BTP application to intercept the authorization code before it reaches the legitimate client.
• Token escrow via shadow APIs: If a BTP service stores tokens for offline use in an API endpoint that lacks proper access control, attackers can enumerate and steal tokens.
• Client secret exposure: Client credentials stored in configuration files, environment variables, or source code repositories (GitHub) allow attackers to issue tokens directly.

Continuous monitoring with CyberSilo SAP Guardian detects these attack patterns by correlating authentication events with known threat signatures and behavioral baselines. The platform covers SNC, SAML, and OAuth monitoring out of the box, reducing the manual effort required to secure these layers.

Compliance and Audit Considerations

Authentication security is a critical component of compliance with SIEM-related compliance frameworks like SOX, ISO 27001, PCI DSS, and GDPR. Each framework imposes specific requirements on how authentication must be implemented and monitored:

• SOX (Sarbanes-Oxley): Requires that only authorized users can access financial systems. Authentication misconfigurations that allow unauthorized logins are reportable control deficiencies. SNC must be enforced for all financial system connections.
• ISO 27001 (A.9.4.2): Requires secure log-on procedures. This includes SNC enforcement for remote access, Logon Ticket timeout policies, and OAuth token expiration management.
• PCI DSS (Requirement 8): Requires unique IDs and multi-factor authentication. While SAP supports MFA via SNC (token devices) and OAuth (password + push), many PCI audits fail because MFA is not enforced for RFC users or administrative accounts.
• GDPR (Art. 32): Requires appropriate technical measures to protect personal data. Weak authentication—especially SSO that passes across unencrypted channels—is a violation risk when processing personal data in HR or CRM modules.

SAP Authentication Best Practices

The following best practices synthesize SAP security notes, industry guidance, and real-world incident patterns into actionable security controls:

• Enforce SNC for ALL connections: Dialog, RFC, CPIC, and external programs. The parameter snc/accept_insecure_cpic must always be 0 in production.
• Use CommonCryptoLib: Migrate from SAPCRYPTOLIB to CommonCryptoLib (SAP Note 2558998). Ensure the library is updated with the latest security patches.
• Limit Logon Ticket lifetime: Maximum 60 minutes for production systems handling sensitive data. Use shorter windows for financial and payroll systems.
• Implement SAML assertion encryption: Use the SAML AuthnRequest and Assertion encryption features to prevent token interception.
• Disable deprecated OAuth flows: Remove Implicit and Resource Owner Password grant types from all BTP subaccounts. Use Client Credentials only with strict scope limitations and secret rotation.
• Integrate authentication logs with SIEM: Forward SM19, SM20, SAP BTP audit logs, and OAuth token logs to your central security monitoring platform. Do not rely on SAP's native logging alone—it lacks correlation across authentication methods.
• Regularly test authentication resilience: Conduct penetration tests that specifically target SNC misconfigurations, SAML signature wrapping, and OAuth scope escalation. Use automated tools to check configurations against SAP security baseline recommendations.
• Monitor for authentication anomalies in real-time: Implement behavioral baselines for each user and system. Alerts should fire on authentication events that deviate from the baseline—not just on failed logins.