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 G Suite customers, you might also
request to become a listed vendor in the
G Suite Marketplace.

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.

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 G Suite 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.

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.

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.

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.

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.