Skip to content

Security Overview

An essential element when planning your mobile services landscape is to provide secure propagation of mobile users' identities to back-end systems. The product supports a range of popular application authentication protocols and maps them to back-end systems. In addition, mobile services and its surrounding tools provide a variety of means of securing data at rest and in motion.


Several factors can help you determine the best security configuration for your mobile applications. The most important factor is your current or planned landscape architecture. The security landscape includes application authentication, transport and session security, and data protection and privacy.

The high-level landscape options are:

  • Cloud – all components run on cloud infrastructure, either SAP Business Technology Platform alone or with another infrastructure provider.
  • Hybrid – components run on SAP Business Technology Platform, and services run in an on-premise landscape.

The mobile services support mobile applications, and each application includes these security properties, which you can configure in SAP mobile service cockpit:

  • A user authentication policy—also called a security configuration—defines the HTTPS protocol to authenticate the user, for example, basic authentication, SAML 2.0, OAuth 2.0, or X.509 user certificates. For more information about supported security configurations, see Application Authentication.
  • One or more back-end HTTP endpoints—also called app URLs—define how an authenticated mobile user’s identity is relayed to back-end systems.

For simple authentication that uses HTTPS basic authentication headers, mobile services support the System for Cross-Domain Identity Management (SCIM) protocol.

SAP Gateway also works with the SCIM server, which is often the simplest, most secure authentication method to use for your hybrid cloud SAP environment.

Feature Scope

Feature Description
Authenticate users Authenticate using popular protocols such as OAuth, SAML or Basic authentication
Propagate user identities Forward user authentication by means of Basic, Application-to-Application SSO, Forward Authentication, SAP Cloud Connector SSO or OAuth2 SAML Bearer Assertion
Virus Scanning Scan inbound and outbound traffic for harmful code and data
Role-based access Secure your applications by creating roles and assigning them to users
User blocking Prevent specific users from further using existing apps or from accessing new ones
User locking Prevent users from using apps that haven't connected to mobile services for a certain period of time
Data wiping Request deletion of client-side data of clients that haven't connected for a certain period of time
Automatic user removal Force re-registration of clients that haven't connected for a certain period of time
Cross-site request forgery (CSRF) protection Protect users from CSRF attacks
Encrypted client data Protect data in apps by means of passcodes and biometrics
Multi-landscape support Build pure cloud solutions or connect to on-premise back ends in hybrid cloud scenarios
Android SafetyNet Attestation API to safeguard your server by examining a device's software and hardware environment, allowing you to determine whether the server is communicating with a genuine app and device, so that you can then decide to accept or reject the client’s requests.
Clipboard protection Disable copying, cutting, and pasting content from one application to another application, while still permitting copying, cutting, and pasting content from one screen of an application to another screen of the same application, including screens on embedded browsers.

Authenticating User Requests

For all user requests that require authentication, send the authentication information to SAP Mobile Services. The credentials, which you provide in the header, depend on the type of security configuration.You can also use OAuth tokens or existing session cookies to authenticate user requests.

  • Basic authentication

    The user name and password should be valid for the specified authentication URL.

    • HTTP Header Name: Authorization
    • HTTP Header Value: Basic <base64 encoded form of username:password>

Authenticating Server Application Requests

Several methods are used to authenticate access requests from customer server applications:

  • Access mobile services through the mobile-approuter, which is protected by OAuth security type. Customer server application has to use a valid user OAuth token issued by the xsuaa service instance of the mobile-approuter application. The token might be received by the customer server application from mobile client applications.
  • Access mobile services through the mobile-approuter, which is protected by Basic security type. Customer server application can use a valid basic authorization header (username and password).
  • Access mobile services directly using the service URL, which is fetched from the service binding of the mobile-approuter application. Service key authentication can be used. Note that currently only the push service and cards service support service key.

Session Cookies

As a SAP Business Technology Platform service, Mobile Services provides two session cookies for maintaining sessions between a mobile app client and Mobile Services:

  • JSESSIONID ‒ session cookie that is used to maintain a session with Mobile Services.

  • __vcap_id__ ‒ session cookie that is used to provide affinity with SAP Business Technology Platform Cloud Foundry.

When accessing a back-end server through Mobile Services, the back-end server might also generate cookies (session or non-session). Mobile Services does not directly return the cookies generated by the back-end server to the client.

The back-end server session cookies are stored in Mobile Services. When a subsequent request is received for the same back-end server, Mobile Services loads the stored session cookies and appends them to the forwarded request to the back-end server. If the client sends multiple requests to Mobile Services in the same session, the back-end server session cookies are included in all subsequent requests, even though the client never receives them.

Each back-end server non-session cookie is wrapped as a new cookie in Mobile Services. The wrapped cookie is returned to the client. The client includes that cookie value in subsequent requests, and Mobile Services unwraps the cookie, and appends the original cookie in the request forwarded to the back-end server.

The format of the wrapped cookie name is:


The value of the wrapped cookie is the Base64-encoded value of the original cookie returned by the back-end server.

For example, the following set-cookie response header is a wrapped cookie:

`set-cookie: cpmscf_proxy___SAPCPMS_669C30CF0569E4856F2A88A53197E3268AC5A985=eyJuYW1lIjoiQkFDS0VORF9DT09LSUUiLCJ2YWx1ZSI6IjEyMzQ1Njc4OSIsInBhdGgiOiIvIiwiZG9tYWluIjoicHJveHltb2NrLW1vYmlsZWRldi1wcm92aWRlci1pbnQtdGVzdC5jZmFwcHMuc2FwLmhhbmEub25kZW1hbmQuY29tIn0; Expires=Thu, 20 Nov 2025 12:06:04 GMT; Max-Age=99999999;; Path=/`

Last update: June 15, 2023