Mobile App Best Practices

If you are developing a mobile app, the following is a checklist of additional steps to take when using Google Sign-In with work accounts for a custom developed application:

  1. If your app knows the Google for Work domain of the account, you should pass that domain to the auth server so only accounts in that domain are displayed during sign-in. On Android, this is done with the setHostedDomain builder method, and on iOS, this is done with the hostedDomain property.

  2. Google's OpenID Connect support can be used for the initial authentication of the user. Your app will then need to authenticate requests to the backend API server.

    Your app should use OAuth 2.0 design patterns when possible: in particular, use a short-lived token for API access that has to be refreshed by sending a long-lived token to the server, which checks whether the account had any big account changes. Such changes might include the employee changing their password since the initial sign-in, or of leaving the company, or of being removed from the group of employees with access to the application. If such a situation is detected, the server does not return a new short-lived token but instead returns an error to the mobile app. When the mobile app receives that error, it immediately deletes any local data it had cached about that account in the app, and then restarts the sign-in process.

  3. With Android apps, an additional level of security can be provided using the SafetyNet API. Every time the app requests a new short-lived API token it can first request a SafetyNet assertion from the phone and then include it in the request to the server. If the server is not able to validate the SafetyNet assertion, then the phone might not be in a safe state. In that case, the server can return an error like in step 1, asking the app to wipe any local data and restart the sign-in process. However, it would be helpful before any sign-in flow to first perform this check and, if it fails, to show an error to the user indicating their device is not in a trustworthy state.

  4. For some apps, it might be important to the company to ensure the mobile phone used to access it have a lock screen. This can be done for Google's Drive, Mail, and other applications using Mobile Management, including its support for Smart Lock for Android. If the app requires a Google Sign-In for the work account, then that initial authentication will only succeed if the device has a lock screen.

    For corporate-owned devices, there are many vendors with more advanced mobile management controls. However, the combination of these first three techniques provides the main controls. Some additional controls can be implemented by monitoring the ongoing state of the device's lock screen:

    • On Android this is available with the function which returns true if a lock screen is set up. No special OS permissions are needed to call this API.
    • On iOS, apps can observe a "device did wake with passcode required" event (the UIApplicationProtectedDataDidBecomeAvailable notification). If your app is running or backgrounded and the iPhone enters a state where the passcode is required to unlock, you can be notified about it. So an app could, for example, observe the user over time, and see if they ever get this notification. The user could even be instructed to sleep & wake the device in a setup flow to prove the setting (which would enforce a "require immediately" passcode setting, but not the "require after x minutes" setting). You can try out this functionality by building the proof-of-concept iOS app.