Securing Enterprise AI on SAP BTP: Zero Trust Authentication with SAP AI Core

[Jana_Cyber]

(Jana Subramanian serves as Head of Cybersecurity and Compliance for SEA and is a Fellow of Information Privacy (FIP), awarded by the International Association of Privacy Professionals (IAPP). In this role, Jana supports strategic customer engagements on cybersecurity, data privacy, multi-cloud security integration architecture, contractual assurance, audit, and compliance.)

Introduction:

If you are building AI-powered applications on SAP BTP with SAP AI Core, understanding how authentication works is essential. This blog walks through the complete SAML-to-OAuth flow from corporate SSO to securely calling AI services, using simple diagrams and clear explanations. Along the way, we also clarify common misconceptions about SAML assertions, token handling, and why your application never deals with SAML directly.

This post does not cover detailed configuration steps. Instead, it focuses on the high-level concepts and end-to-end flow to help you build a clear mental model of how authentication works in SAP BTP.  By the end, you will understand the overall process from user login to AI inference, illustrated step-by-step for easier comprehension.

Step: 1

User Enters Application URL The authentication journey begins when a user opens their web browser and enters the URL for the SAP BTP application. At this initial stage, the user is unauthenticated, and the browser sends an HTTP GET request (unauthenticated at this stage). This step represents the standard entry point where the user knocks on the door of the application before any security checks are applied.

Step 2:

Traffic Reaches App Router / Application Once the traffic reaches the SAP BTP Application (or App Router), the component acts as a security gatekeeper. It immediately inspects the request to see if a valid session or OAuth 2.0 JWT token already exists. In this scenario, because it is a new login attempt, no valid token is found, and the application recognizes that it must initiate the authentication process to protect its resources .

Step 3:

Application Redirects to XSUAA Instead of handling authentication itself or sending the user directly to the corporate Identity Provider, the application redirects the user's browser to XSUAA, the platform's OAuth 2.0 Authorization Server. This is a critical architectural design: the application initiates a standard OAuth Authorization Code Flow, effectively delegating all complexity regarding SAML and corporate identity to XSUAA.

Step 4:

XSUAA Generates SAML AuthnRequest & Redirects to IdP XSUAA now takes over the orchestration by generating a SAML Authentication Request (AuthnRequest) and redirecting the user's browser to the corporate Identity Provider (IdP), such as Azure AD or Okta . By handling this step, XSUAA acts as the Service Provider on behalf of the application, managing the trust configuration and specific SAML protocol requirements so the application doesn't have to.

Step 5:

Authenticates User and Issues SAML Assertion The user completes their login at the corporate IdP (using passwords or MFA), and upon success, the IdP generates a cryptographically signed SAML assertion . Crucially, the browser POSTs this assertion directly to XSUAA's Assertion Consumer Service (ACS) endpoint—not to the application. This ensures the application never touches the XML or handles the certificate validation, keeping the application logic clean and secure.

Step 6:

XSUAA Performs SAML to OAuth Token Exchange Upon receiving the SAML assertion, XSUAA validates the digital signature and timestamps, and automatically maps the SAML attributes to OAuth scopes . Once validation passes, XSUAA generates an OAuth 2.0 authorization code and redirects the browser back to the application's callback URL with this code in the query string . This step effectively translates the enterprise SAML identity into a modern OAuth artifact transparently.

Step 7:

Application Exchanges Authorization Code for OAuth Tokens The application receives the authorization code and immediately performs a secure, server-to-server POST request to XSUAA to exchange it for an access token and a refresh token . Because this request includes the application's Client ID and Client Secret, XSUAA verifies the application's identity before issuing the tokens, which are then stored securely in the server-side session .

Step 8:

Application Calls GenAI Hub API Using Access Token With a valid OAuth access token securely stored, the SAP BTP application can now invoke the Generative AI Hub. To do this, the application sends an HTTP request—typically a POST—to the GenAI Hub API endpoint containing the user’s input or inference prompt. The most important part of this request is the Authorization header, where the application includes the JWT access token using the standard OAuth bearer format (Authorization: Bearer <JWT>) . This step represents the handoff from authentication to operation: the application is no longer proving identity but instead using the validated token to access protected AI services. The GenAI Hub will then independently validate the JWT before forwarding the request to SAP AI Core for model execution.

Step 9:

Gen AI Hub Validates JWT LOCALLY When the application makes an API call to the Gen AI Hub using the access token, the Hub validates the token locally rather than calling back to XSUAA . By using cached public keys (JWKS) from XSUAA, Gen AI Hub can instantly verify the token's signature, expiration, and scopes . This local validation approach significantly reduces latency (from ~100ms to ~10ms) while maintaining cryptographic security.

Step 10

AI Core Independently Validates JWT (Zero Trust) Adhering to Zero Trust principles, when Gen AI Hub forwards the request to SAP AI Core, AI Core does not blindly trust the previous validation . Instead, it independently validates the token again using the same local JWKS method to verify the signature and ensure the user has the specific permissions required for the target resource group . This defense-in-depth strategy ensures that even if an upstream service were compromised, unauthorized access is prevented.

Step 11:

Response Returns to User After the AI Core executes the inference on the model, the results travel back up the chain—from AI Core to Gen AI Hub, and finally to the application . The application receives the AI-generated response and renders it to the user interface. The user sees the result immediately, completely unaware of the sophisticated "authentication dance" and multi-layered security checks that occurred in the background.

Complete Authentication and Authorization Flow:

The complete architecture brings all these components together, visualizing the robust interplay between the User, App Router, XSUAA, Identity Provider, and AI services. It highlights the separation of concerns where XSUAA manages identity federation, the application handles business logic via OAuth, and the backend AI services enforce security through independent, local Zero Trust validation.

If you still have a challenge in understanding technicalities, here is a layman point of view for better comprehension:

1. You want to enter the building (BTP App)
2. Security guard (App Router) says "Show me your badge"
3. You don't have one, so guard sends you to Badge Office (XSUAA)
4. Badge Office says "Prove you work here - go to HR (IdP)"
5. HR checks your ID (username/password + MFA)
6. HR gives you a signed letter (SAML) for Badge Office
7. Badge Office checks HR's signature ✓
8. Badge Office gives you a CLAIM TICKET (authorization code) - NOT the badge yet!
9. You give the claim ticket to the guard (App Router)
10. Guard takes your claim ticket + their secret password to Badge Office
11. Badge Office verifies claim ticket + guard's credentials
12. Badge Office NOW gives the guard your access badge (OAuth token)
13. Guard stores your badge securely and lets you in
14. Inside building, each room (Gen AI Hub, AI Core) scans your badge
15. Each room verifies badge locally using master key
16. You get access

Common Misconception

#	Misconception	Reality (Correct Explanation)
1	The application receives or processes the SAMLResponse.	The SAMLResponse is posted only to XSUAA (ACS endpoint). The application never interacts with SAML.
2	XSUAA forwards the SAML assertion to the application.	XSUAA converts the SAML assertion into an OAuth Authorization Code, then into JWT tokens. No SAML leaves XSUAA.
3	SAP BTP applications authenticate directly with the IdP.	Apps authenticate only with XSUAA, not the IdP. The IdP authenticates users, not applications.
4	GenAI Hub or AI Core call XSUAA to validate JWTs.	Both services validate tokens locally using JWKS. No introspection call is made to XSUAA.
5	AI Core does not need to revalidate the JWT if GenAI Hub validated it already.	AI Core enforces Zero Trust and performs its own independent JWT validation.
6	OAuth Authorization Codes are long-lived.	Authorization Codes are short-lived (seconds) and single-use only.
7	Token lifetimes are fixed and universal.	Token lifetimes (access/refresh/session) are configurable per subaccount or client.
8	JWTs contain passwords or sensitive authentication data.	JWTs include claims only (audience, scopes, expiry, user ID). Credentials and MFA data never appear inside a token.
9	OAuth tokens are returned through browser redirects.	Token exchange happens only server-side between the app backend and XSUAA. Tokens never travel in URLs.
10	GenAI Hub or AI Core receive SAML attributes.	Downstream services receive JWT scopes, not SAML attributes. SAML-to-scope mapping happens in XSUAA.
11	The application should call AI Core directly.	Best practice: App → GenAI Hub → AI Core. GenAI Hub manages token validation, routing, and observability.
12	Refresh tokens are always issued.	Refresh tokens are issued only if allowed by the OAuth client configuration.
13	The IdP decides which OAuth scopes the app gets.	IdP only provides identity attributes. XSUAA assigns scopes based on role collections and SAML group mappings.
14	SAML and OAuth are separate flows.	They form a single chained flow: SAML user authentication → XSUAA → OAuth token issuance → JWT for APIs.

Key Benefits

Benefit	Why It Matters	How the Architecture Enables It
1. Clear Separation of Concerns	Reduces application complexity and security risk.	XSUAA absorbs all SAML, federation, and identity-provider logic; applications speak only OAuth.
2. Seamless Single Sign-On (SSO)	Smooth user experience with no repeated logins.	SAML authentication happens once via the corporate IdP; OAuth tokens propagate downstream automatically.
3. Zero Trust Validation	Ensures no service blindly trusts another—improves overall security posture.	GenAI Hub and AI Core independently validate JWTs locally using JWKS.
4. Defense-in-Depth Security	Multiple layers of verification block misuse even if one component is compromised.	SAML assertions validated at XSUAA → JWT validated at GenAI Hub → validated again at AI Core.
5. No Exposure of SAML to Applications	Prevents incorrect handling of complex SAML logic by developers.	All SAML exchanges occur strictly between IdP and XSUAA (ACS endpoint).
6. Standards-Based Interoperability	Easier integration, maintainability, and compatibility with enterprise systems.	Uses industry standards (SAML 2.0, OAuth 2.0, JWT, JWKS).
7. High Performance Token Validation	Reduces network latency and improves inference speed.	Local JWT validation avoids calls back to XSUAA for each request.
8. Scalability Across Services	Allows multiple SAP services to trust the same identity securely.	A single JWT can be validated independently by GenAI Hub and AI Core.
9. Strong Cryptographic Guarantees	Protects against tampering, interception, and replay attacks.	Signed SAMLResponse + signed JWT + short-lived authorization codes.
10. Invisible Complexity for End Users	Users face no friction, even though the architecture is advanced.	Redirects, token exchanges, and validations happen fully behind the scenes.
11. Centralized Identity Governance	Simplifies role management and compliance.	XSUAA handles role collections, scope assignment, and mapping from IdP attributes.
12. Clean Application Code	Faster development, fewer bugs, and clearer security boundaries.	Application deals only with Bearer tokens—never SAML assertions or IdP protocols.

Conclusion

We have now traced the complete lifecycle of a request starting from a simple browser click and ending with a sophisticated AI inference. The elegance of this architecture lies in its separation of concerns. XSUAA handles the heavy lifting by absorbing all the complexity of SAML and corporate identity federation, allowing your application to stay clean and focused, speaking only standard OAuth. Just as important, security on SAP BTP is not a single gate check. Through local JWT validation and Zero Trust principles, services such as the Generative AI Hub and SAP AI Core independently verify every incoming request using cached public signing keys. This provides true defense in depth without compromising performance.

For the end user, all of this, redirects, token exchanges, validations, and cryptographic guarantees, remains completely transparent. They log in once and simply get to work. By understanding the rationale behind these architectural diagrams, it is easier to design SAP Business AI driven applications that are operationally robust and secure by design.

Disclaimer:

© 2025 SAP SE or an SAP affiliate company. All rights reserved. See Legal Notice on www.sap.com/legal-notice for use terms, disclaimers, disclosures, or restrictions related to SAP Materials for general audiences.