CX Works

A single portal for curated, field-tested and SAP-verified expertise for your SAP Customer Experience solutions. Whether it's a new implementation, adding new features, or getting additional value from an existing deployment, get it here, at CX Works.

SAP Customer Data: Mobile Application Best Practices

Mobile Applications with SAP Customer Data Cloud

Table of Contents

Mobile SDKs considerations

SAP Customer Data Cloud provides official mobile SDKs for Android, iOS, and Cordova. These SDKs provide access to SAP Customer Data Cloud's core API, while providing support for features such as session management, screen-sets, social login, biometric and two-factor authentication.

When viable, your mobile applications should implement SAP Customer Data Cloud using these SDKs. Some key elements of this approach are:

  • SAP Customer Data Cloud provides ready-for-use SDKs to easily manage interaction with its APIs.
  • Mobile SDKs features are currently used by thousands of users in production (sports, media, automotive, others).
  • Implementing social login in a mobile application is possible with minimum effort. SDKs include wrappers for the most popular social providers native SDKs (i.e. Google, Facebook, LINE, WeChat). Furthermore, your mobile application require minor effort to incorporate changes made by social providers authentication flows as well as changes these providers decide to do in future themselves.
  • Session management is performed by the Mobile SDK. There is no need for your development teams to implement custom keychain-like storing mechanism for token management and refresh token.


Figure 1. Mobile application without VS with SAP Customer Data Cloud Mobile SDK


Figure 2. Sample architecture with mobile application using SAP Customer Data Cloud Mobile SDK


Security considerations

Secret keys

A mobile application that interacts with SAP Customer Data Cloud is considered a client-side application or public client. Therefore, it is important not to store secret keys in the source code of a mobile application. A malicious user with basic technical knowledge could decompile the app, and retrieve sensitive information. Secret Keys (partner secret, user/app secret) should only be used in server-server calls and should never be passed to the client-side application.

Biometric authentication

Biometric authentication enables a much higher level of security in mobile applications by using biometric identification to verify that the user is, in fact, the device owner. When this feature is enabled in SAP Customer Data Cloud iOS and Android SDKs, sessions are encrypted with a biometric key. This biometric identification is usually either face or fingerprint.

It is important to remember that biometric authentication does not replace SAP Customer Data Cloud traditional authentication mechanisms (i.e. login ID + password or social login or enterprise federation). The biometric authentication feature is a security encryption on top of an existing session of the mobile application, therefore, calling any biometric operations requires a valid session.

Biometric authentication, just like other security measures, will have an impact in the user experience and might not be the best option for all types of mobile applications. Apps which contains sensitive data like finance, banking, or those doing transactions relating to money, require higher degree of security. In such risky apps, integration of biometric authentication is more favorable. For such data sensitive apps, face or fingerprint authentication should be asked every time they need to access the app and/or specific operations within the app.

Two-factor authentication

SAP Customer Data Cloud offers a feature called "Two-factor authentication" as part of the Risk-Based authentication offering. When TFA is enabled for a user's account, it will require them to enter a code received to their phone or email in order to login to the mobile application. When deciding between standard authentication, biometric, and TFA, customers should evaluate the differences between these features and how can they work side-by-side to increase security in a mobile application.


Biometric authentication Two-factor authentication (RBA)
Intended to validate device ownership due to long-lived sessions on mobile apps Intended to validate account ownership due to possible hacking attempts from different countries or devices
Makes it more difficult to extract session information from the mobile device by applying encryption Prevents malicious login attempts on the account by confirming possession of a registered trusted device
Relies on Android/iOS Operating System Biometric API Relies on SAP Customer Data Cloud - Risk Based Authentication layer
Configured in the Android Studio / XCode project Configured in the SAP Customer Data Cloud Admin Console
Enforced only in iOS and Android apps Enforced across all platforms if TFA is enabled on the API Key (REST API, Web, Mobile, IoT)
Triggered when app is re-opened and on-demand Triggered on login attempts
Requires a valid session. Cannot be triggered if user is not successfully logged in Is part of the login process. User must pass TFA to obtain session information



Implementation considerations

WebView is an essential component in both Android and iOS platforms. However, trying to server entire web applications, for instance SAP Customer Data Cloud-enabled websites in a native's WebView component is not advisable, as the mobile application can rapidly run into issues. Some known complications are:

  • Social Providers (i.e. Google, Facebook) explicitly block login requests made via WebView.
  • Android and iOS have different underlying WebView components. Too many edge cases and bugs to address in order to ensure a web application works on each OS WebView.
  • WebView interactions with your custom JavaScript might cause unexpected issues (jQuery, Cross Origin policy, others).
  • Slow speed in loading the application and the screens, compared fully native applications.
  • Websites served in a WebView are usually “fast enough” or “good enough”, but in mobile development this is the wrong mentality to have. For instance, clause 4.2 of Apple’s Developer Guidelines says: “Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store”.

Therefore, to implement SAP Customer Data Cloud on mobile applications in a supported way, we recommend following one of the approaches described below.

Full Native

In a native approach, developers write code entirely (or almost entirely) in a language that is natively provided by iOS or Android (Swift, Kotlin, Java, Objective-C). The construction of the mobile application, design, graphic styles, typography, and others varies between the operating systems. In the context of SAP Customer Data Cloud, a mobile application that implements custom-native CIAM screens (instead of using SAP Customer Data Cloud Screen-Sets) is considered "full native".

A mobile application with custom screens will then interact with SAP Customer Data Cloud APIs through a Mobile SDK to execute authentication and profile management operations.

The following code snippet illustrate how a fully native application could interact with the Mobile SDK to send a login requests, with loginID and password values captured from a custom screen. 

mGigya.login("LOGIN-ID", "PASSWORD", object : GigyaLoginCallback<MyAccount>() {
    override fun onSuccess(obj: MyAccount) {
        // Success
    }
    override fun onError(error: GigyaError) {
        // Fail
    }
})

Screen-Sets via PluginView

This approach consists in using & displaying SAP Customer Data Cloud screen-sets in a mobile application. The screen-sets can be displayed in a native application thanks to a dedicated "PluginView" component in the Mobile SDKs. The PluginView is based on a specialized WebView that will appear containing the screen-sets. This view is controlled by the Mobile SDK and is able to propagate the different events (i.e. onSubmit, onBeforeValidation, onBeforeScreenLoad) and related objects to the mobile application’s level.

The following code snippet illustrate how a mobile application could display a SAP Customer Data Cloud Screen-Sets.


mGigya.showScreenSets("Default-RegistrationLogin", false, null, new GigyaPluginCallback<MyAccount>() {
    @Override
    public void onLogin(@NonNull MyAccount accountObj) {
       // Login success.
    }
});


Figure 3. Screen-set on a mobile application using SAP Customer Data Cloud Mobile SDK (PluginView)


Screen-Sets via WebBridge

This is a similar approach as PluginView but it needs to point to a URL hosted by the customer (similar to iFrame). It relies on a Mobile SDK functionality called "GigyaWebBridge". It is a special class that allows attaching the SAP Customer Data Cloud Web SDK actions into your own WebView implementation. In other words, you can render an existing Webpage containing Screen-Sets in your mobile application (via WebView), and the WebBridge will take care of the communication between the Mobile SDKs and Web SDK embedded in the WebView.

Special cases when WebBridge might be an ideal approach include uses of SAML & captcha implementations.






Conclusion

This article has presented expert guidance for building mobile applications with SAP Customer Data Cloud, taking in consideration best practices from our professional services teams and previous implementations. We've given you a detailed description of the recommended approaches to enable CIAM in a mobile application using SAP Customer Data Cloud Mobile SDKs. We have covered some important security considerations to have in mind when designing a mobile application.

To access all our community or out of the box product documentation, please check out our List of Online Resources.