Bonnes pratiques relatives aux applications mobiles

Si vous développez une application mobile, voici une liste de contrôle des étapes supplémentaires à suivre lors de l'utilisation de Google Sign-In avec des comptes professionnels pour une application développée personnalisée:

  1. Si votre application connaît le domaine G Suite du compte, vous devez transmettre ce domaine au serveur d'authentification afin que seuls les comptes de ce domaine soient affichés lors de la connexion. Sur Android, cela se fait avec la méthode de générateur setHostedDomain , et sur iOS, cela se fait avec la propriété hostedDomain .

  2. La prise en charge OpenID Connect de Google peut être utilisée pour l'authentification initiale de l'utilisateur. Votre application devra ensuite authentifier les demandes auprès du serveur API backend.

    Votre application doit utiliser les modèles de conception OAuth 2.0 lorsque cela est possible: en particulier, utilisez un jeton de courte durée pour l'accès aux API qui doit être actualisé en envoyant un jeton de longue durée au serveur, qui vérifie si le compte a subi des modifications importantes. Ces changements peuvent inclure le changement de mot de passe de l'employé depuis la connexion initiale, ou de quitter l'entreprise, ou d'être retiré du groupe d'employés ayant accès à l'application. Si une telle situation est détectée, le serveur ne renvoie pas de nouveau jeton de courte durée, mais renvoie à la place une erreur à l'application mobile. Lorsque l'application mobile reçoit cette erreur, elle supprime immédiatement toutes les données locales qu'elle avait mises en cache à propos de ce compte dans l'application, puis redémarre le processus de connexion.

  3. Avec les applications Android, un niveau de sécurité supplémentaire peut être fourni à l'aide de l' API SafetyNet . Chaque fois que l'application demande un nouveau jeton d'API de courte durée, elle peut d'abord demander une assertion SafetyNet au téléphone, puis l'inclure dans la demande adressée au serveur. Si le serveur n'est pas en mesure de valider l'assertion SafetyNet, il se peut que le téléphone ne soit pas dans un état sûr. Dans ce cas, le serveur peut renvoyer une erreur comme à l'étape 1, demandant à l'application d'effacer toutes les données locales et de redémarrer le processus de connexion. Cependant, il serait utile avant tout flux de connexion d'effectuer d'abord cette vérification et, en cas d'échec, d'afficher une erreur à l'utilisateur indiquant que son appareil n'est pas dans un état de confiance.

  4. Pour certaines applications, il peut être important pour l'entreprise de s'assurer que le téléphone mobile utilisé pour y accéder dispose d'un écran de verrouillage. Cela peut être fait pour Google Drive, Mail et d'autres applications utilisant Mobile Management , y compris sa prise en charge de Smart Lock pour Android . Si l'application nécessite une connexion Google pour le compte professionnel, cette authentification initiale ne réussira que si l'appareil dispose d'un écran de verrouillage.

    Pour les appareils appartenant à l'entreprise, de nombreux fournisseurs proposent des contrôles de gestion mobile plus avancés. Cependant, la combinaison de ces trois premières techniques fournit les principaux contrôles. Certains contrôles supplémentaires peuvent être mis en œuvre en surveillant l'état en cours de l'écran de verrouillage de l'appareil:

    • Sur Android, cela est disponible avec la fonction android.app.KeyguardManager.isKeyguardSecure() qui renvoie true si un écran de verrouillage est configuré. Aucune autorisation spéciale du système d'exploitation n'est nécessaire pour appeler cette API.
    • Sur iOS, les applications peuvent observer un événement «l'appareil s'est réveillé avec le code d'accès requis» (notification UIApplicationProtectedDataDidBecomeAvailable ). Si votre application est en cours d'exécution ou en arrière-plan et que l'iPhone entre dans un état dans lequel le code d'accès est requis pour le déverrouillage, vous pouvez en être informé. Ainsi, une application peut, par exemple, observer l'utilisateur au fil du temps et voir s'il reçoit jamais cette notification. L'utilisateur pourrait même être invité à mettre en veille et à réveiller l'appareil dans un flux de configuration pour prouver le paramètre (ce qui imposerait un paramètre de code d'accès «exiger immédiatement», mais pas le paramètre «exiger après x minutes»). Vous pouvez essayer cette fonctionnalité en créant l' application iOS de preuve de concept .