Check out our new one-tap sign-up and auto sign-in experience for the web!

Mobile App Best Practices

The following is a checklist of suggested steps to take when using Google Sign-In with work accounts for a mobile SaaS app. These are suggested best practices for SaaS developers. It can be very complex to implement sign-in well, so consider using software and services that handle most of this for you. Google Identity Toolkit is one option, but you might also evaluate other vendors that support these standards such as Ping Identity. After your SaaS sign-in supports Google for Work customers, you might also request to become a listed vendor in the G Suite Marketplace.

  1. Very few SaaS apps require Google Sign-In for all their users, so first determine if the end-user should try to authenticate with Google Sign-In. There are multiple ways to do this. Google itself acts as relying party to thousands of companies who run their own identity provider. If you look at Google mobile apps you will see that the first step of the sign-in flow just asks for an email address. After that is entered, the app can determine if the user should be redirected to an identity provider or authenticated with a password. Not all apps have a single account per email address though, and those others generally need to first ask the user for their tenant name. Other variants of this are also possible.

    If your app is running on Android, consider integrating with Smart Lock for Passwords to remember the user's choice the next time they interact with the app.

  2. After the first step is done, if the app determines that the account should be authenticated with Google Sign-In, we suggest using our Android or iOS SDK. 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.

  3. After you get an OpenID Connect assertion from Google, check that Google confirmed it is an account controlled by the administrators of the domain name. See Authenticate with a backend server. Then, use the asserted email address to find the account record in your system. However, the sub value in the ID token is a more stable identifier, so the preferred approach is for the company to have provisioned the account in your system ahead of time including giving you that sub ID.

  4. 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.

  5. 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, 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.

  6. 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 android.app.KeyguardManager.isKeyguardSecure() 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.