Access and Refresh Tokens

Device security for ServiceNow Mobile apps Device security for ServiceNow Mobile apps

This document applies to current ServiceNow apps for iOS and Android for Vancouver . This document may be subject to change for future mobile releases.

Parent Topic: Mobile security Components and architecture

The ServiceNow mobile apps consist of the ServiceNow server instance and native apps for iOS and Android. The apps use fully native code and are not a hybrid approach. The mobile client applications communicate over a wireless connection with the server and pull live data for the end user.

Component explanations Apps for iOS

The ServiceNow apps for iOS are fully native iPhone and iPad applications. The applications can be pulled, dynamically configured, and distributed using MDM (more information available in EMM section). ServiceNow does not currently distribute the ipa file to customers.

Apps for Android

The ServiceNow apps for Android is a fully native applications for Android phone. They can be downloaded from the Google Play store directly by a user, or can be pulled, dynamically configured, and distributed using MDM (more information available in EMM section). ServiceNow only supports apk file distribution to customers for branded versions of Android mobile apps. For details on branded applications, see Mobile Publishing .

Identity and access management

Learn about user authentication, third party authentication, and user session termination for mobile applications.

For more information, see User authentication for ServiceNow mobile apps .

User authentication for ServiceNow mobile apps

ServiceNow mobile apps support platform authentication using OAuth 2.0. Authentication mechanisms include multi provider SSO, MFA, LDAP, Local DB, and Digest.

AppAuth authentication The ServiceNow mobile apps use a new authentication methodology called AppAuth. AppAuth uses an external mobile browser to log the user in. The following steps detail login using AppAuth. The client creates and records a secret named the code_verifier , and derives a transformed version t(code_verifier) (referred to as the code_challenge ). This code_challenge is sent in the OAuth 2.0 Authorization Request along with the transformation method t_m . The Authorization Endpoint responds as usual but records t(code_verifier) and the transformation method. The client then sends the authorization code in the Access Token Request as usual but includes the code_verifier secret generated in the previous steps. The authorization server transforms code_verifier and compares it to t(code_verifier) from the previous steps. Access is denied if they are not equal.

Figure 1. Abstract protocol flow

Single sign-on ServiceNow mobile apps require multi-provider single sign-on in order to use external authentication. The multi providers SSO plugin [com.snc.integration.sso.multi.installer] provides SAML authentication support. The login process (AppAuth) uses this plugin to redirect the user to the IDP (SAML provider) login page when using SAML.

For more information on this plugin, see External single sign-on (SSO) .

For more information on configuring multi provider SSO, see Multi-Provider Single sign-on (SSO) .

Multifactor authentication Users can access the instance via Multifactor Authentication using the MFA plugin [com.snc.integration.multifactor.authentication]. Users are directed to their login page after selecting their instance in a mobile app.

Figure 2. Multifactor login page in the Mobile Agent app

For details on configuring Multi-factor Authentication, see Multifactor authentication system properties

LDAP Use LDAP authentication to access using LDAP credentials. The user sees the same login page as the local login (DB based) but the back end to the LDAP server deletes the authentication. For more information on LDAP configuration, see LDAP integration .

Local DB The user name and password in the user record in the instance database.

Not officially supported Kerberos Certificate-based authentication (AppAuth’s external browser may solve for some certificate based mechanisms)

Storage/Keychain

When you sign in to an app on your mobile device, the app uses your credentials to negotiate an OAuth Token with the instance. The iOS Keychain stores the token and Android uses KeyStore. The keychain encryption is AES 256 in Galois/Counter Mode (GCM).

The ServiceNow mobile apps never store the user password.

The mobile app does store the Client ID which is necessary for getting the oAuth token as part of the authentication flow.

Access and Refresh Tokens

ServiceNow mobile apps use access and refresh tokens to determine valid user sessions.

At first login, a user is given an access token and a refresh token. These tokens are valid for a configurable amount of time. When the user opens a mobile app, the client checks to see if the access token is valid. If valid, the user is able to continue with the session. If not valid, the client then checks if the refresh token is valid. If valid, the refresh token is used to fetch a new valid access token for the user, and the session can continue. If the refresh token is not valid, the user must re-authenticate.

User termination

When an administrator deletes or removes a user from the system, the Access Token is no longer valid and any operation will log the user out.

Mobile data flow for ServiceNow mobile apps

Data can be retrieved, downloaded from, and written back to a mobile device.

Retrieval

The following describes how data is retrieved from ServiceNow mobile apps.

Read data When a user requests to view information on the mobile app, the following steps occur. The mobile app sends a request to access data from the instance. The request includes the token and any relevant data field needed for the request. The instance receives the request and checks if the Token is valid. If the token is valid, the request is directed to the relevant API to fetch the information. The information is returned to the mobile app.

Downloading documents When a user requests to download documents from the app, the following steps occur. The mobile app sends a request to access the document. The request includes the Token. The instance receives the request and checks if the Token is valid. If valid, the document becomes available to view or take further actions on the device.

Write-backs

The following describes how data is written back from ServiceNow mobile apps.

Updating fields When a user updates a field in a mobile app, the following steps occur. The mobile app sends the Token and the action metadata, for example the ID, or the field to be updated, to the instance. The instance directs the action based on the relevant API. The instance completes the action and sends a response to the mobile app. Based on the response, the mobile app reflects the field changes and action availability in the UI.

Attaching documents When attaching documents, the following steps occur. The mobile app asks the user to attach a document, for example, an image. The mobile app sends the document and Token to the instance. The instance places the document based on the relevant API. The instance sends a response back to the mobile app.

Internal mobile app distribution

Internal distribution of ServiceNow mobile apps is supported through all major EMM vendors.

Customers are able to pull the app for iOS or Android from the Apple App store and Google Play respectively, dynamically configure the apps to point to the correct ServiceNow instance, and distribute using the EMM hub. This way, the MDM can fully manage the app as part of a customer portfolio. Note: ServiceNow does not currently distribute the ipa files, or any other unpublished app to customers as it breaches the Apple Enterprise Developer License Agreement.

Mobile app distribution providers: Airwatch: For more information, see AirWatch Mobile Device Management (MDM) Blackberry: For more information, see BlackBerry Unified Endpoint Management (UEM) Intune: For more information, see Intune mobile device management (MDM) IBM: For more information, see IBM Maas360 mobile device management (MDM) MobileIron - For more information, see MobileIron Mobile Device Management (MDM)

Data security for ServiceNow mobile apps

ServiceNow mobile apps use SSL/TLS for Over-the-Air (OTA) communication encryption for data security. The OAuth authorization endpoints are HTTPS.

Data stored in your mobile apps Application preference data such as favorites, home screen, and the mobile navigator items are stored and cached locally on the mobile device. ServiceNow mobile apps do not store record data such as incidents and problems on the device unless your organization has specifically enabled offline syncing for Field Service . The record data is encrypted with AES 256.

Information stored in mobile apps Databases User defined instances Favorite application IDs Push Notifications Geolocation updates Offline data Preferences stored in mobile apps sys_id, display name, username, and initials of the current user URL and name of the current instance Last activity timestamp Encrypted PIN code Offline cache warning period Server Properties LOCATION_PROXIMITY IS_PIN_CODE_REQUIRED IS_BLURRED_IN_BACKGROUND IS_BLOCK_ATTACHMENT_SHARING LOCATION_TRACKED IS_CLEARING_CLIPBOARD_IN_BACKGROUND IS_HIDE_APPLICATIONS_SCREEN_IMAGE IS_OFFLINE_ENABLED LOCATION_FREQUENCY key_analytics_initial_app_launch flag Information stored in the system Account Manager Login date Instance URL Access Token Refresh Token

Data in motion Data in motion is over a secure SSL/TLS channel and encrypted with HTTPS.

Offline access and data cache configuration Choose specific screens and actions to be enabled offline from with Mobile App Builder . On the mobile device, your users can select offline and choose to “cache data" from Settings. The offline flows that you designate are downloaded and cached to the device.

You can encrypt offline cached data by using native encryption. This encryption expires at a specified period of time. The default is 48 hours or when a user signs out of the mobile app.

Offline data is protected by local-auth and the app PIN that can be optionally enabled by administrators. When enabled, users are required to enter a PIN on login, or when the application is inactive for five minutes.

Disabling mobile attachments You can disable attachments for mobile apps by using access control rules. For more details on this process see Disable attachments in mobile apps .

Push notifications

Administrators create push notifications and users are able to receive them.

Cloud For more information on the push notification system including process, configuration, and architecture, see Push notification system . Administrators can configure push notification delays using scheduled jobs . To view an example included with the base system, navigate to System Scheduler > Scheduled jobs , then search for a job with the name Push. 5 seconds is the minimum time allowed for the push delay.

Mobile security practices

Mobile security practices include mobile-specific system properties, attachment control, password reinforcement, security patching, and controlling shared data.

Security controls

Configure security controls to restrict copy/paste, enforce PIN, or block attachment functionality.

Restrict copy/paste Copy/paste restrictions are defined in the system properties [sys_properties] table. There are two applicable security properties.

glide.sg.clear_pasteboard_when_background : Clears the copy/paste clipboard when a ServiceNow app enters the background. For more information on clearing the clipboard, see Configure clear clipboard .

Require an app PIN Require users to enter a six digit PIN each time they sign in from their mobile device, or when an app has been inactive for five minutes. Requiring an app PIN is controlled by the glide.sg.require_mobile_application_pin system property. For more information on requiring an app PIN, see Require an app PIN .

Disabling attachments on a mobile device Use an ACL to block specific access on mobile. Use the isMobile method to check if a request comes from a mobile device. For example, you could add an ACL for the attachment [sys_attachment] table where the read and write scripted ACLs includes the following check. You can also add this code to any existing ACLs you have for the attachment table. If have multiple attachment ACLs, all of the need to have Admin override option unchecked. if( gs.isMobile() ){ answer = false; }

Note: You need elevated privileges to create ACLs.

Enable the blur app option Blur a mobile app when not in focus on a mobile device using the following system property in the system properties [sys_properties] table.

glide.sg.blur_ui_when_backgrounded Important: The glide.sg.blur_ui_when_backgrounded system property is supported on both iOS and Android devices. By default, the value for this property is set to false, which turns it off. For Android devices, when this property is enabled by setting the value to true, the following restrictions apply:

The screen share feature isn't supported and the shared app screen appears black. Users are prevented from taking screenshots.

These restrictions don't apply to iOS devices when the glide.sg.blur_ui_when_backgrounded property is enabled.

For more information, see Configure the blur app option

Block rooted and jailbroken devices To improve security on your mobile device, block the logging in of mobile apps when a rooted or jailbroken device is used. Use the following security property:

glide.sg.allow_rooted_jailbroken_devices system

For more information, see Configure the status for rooted and jailbroken devices .

Penetration testing ServiceNow engages a third party to perform penetration testing of a mobile app. This typically happens annually but sometimes occurs more frequently. The results of these tests are available to customers on CORE. Customers can test the mobile application in conjunction with a pen test of their instance per the process outlined in KB0538598 .

Security patching

In the event a security patch is needed, the mobile development team aligns with standard SDLC properties in order to patch.

User data collection

ServiceNow mobile apps do not specifically collect any user data.

Any user transactions or usage within an app is tracked on the ServiceNow instance just as it is on the web. For user credentials, after a user logs in, the mobile app negotiates an OAuth Token that is stored in the Apple Keychain or the Android Keystore. User credentials are never saved. If the user opts in, the following information is collected: Location Access to camera Notifications

Shared data

ServiceNow mobile apps communicate with a third party software for app crash reporting. No customer information is shared.

iOS : Uses Crashlytics for crash reporting.

Android : Uses Crashlytics for crash reporting.

Incident reporting

ServiceNow mobile app issues should be reported through the standard support channels. You can report incidents by contacting Customer Service and Support.

To report incidents, contact Customer Service and Support .