L'authentification mobile pour vos applications iOS et Android
Une bonne authentification mobile ouvre le navigateur système pour la connexion, utilise le flux authorization code avec PKCE d'OAuth 2.1 et garde l'utilisateur connecté grâce à un jeton de rafraîchissement hors ligne renouvelé à chaque utilisation. Skycloak Platform est conçu pour assurer cette connexion pour vos applications natives, si bien que votre application ne manipule jamais elle-même un mot de passe.
Pourquoi les applications natives se connectent par le navigateur système
Une application native qui affiche ses propres champs d'identifiant et de mot de passe, ou qui charge la page de connexion dans une web view intégrée, peut lire le mot de passe de l'utilisateur et habitue les utilisateurs à le saisir sur n'importe quel écran qui le demande. Le modèle recommandé pour les applications natives consiste à ouvrir la page de connexion dans le navigateur système, ou dans l'onglet de navigateur intégré que fournit le système d'exploitation, dont votre application ne peut pas lire le contenu. L'utilisateur s'y connecte, puis le navigateur renvoie un code d'autorisation à votre application par une redirection. Comme le navigateur conserve déjà la session et les identifiants enregistrés de l'utilisateur, se reconnecter est souvent plus rapide que de remplir un formulaire.
Une application mobile ne peut pas garder de secret client, puisque n'importe qui peut décompresser l'application et le lire, et c'est pourquoi OAuth 2.1 impose PKCE (proof key for code exchange) pour ce flux. L'application crée un secret aléatoire à chaque connexion, en envoie une empreinte avec la requête, puis envoie le secret lui-même lorsqu'elle échange le code contre des jetons. Une autre application qui intercepterait la redirection obtiendrait un code inutilisable, faute de connaître le secret. La plateforme parle OpenID Connect et OAuth 2.1, si bien que toute bibliothèque cliente standard qui suit ce modèle peut connecter vos utilisateurs.
Comment les jetons hors ligne gardent les utilisateurs connectés
Les utilisateurs s'attendent à ce qu'une application mobile se souvienne d'eux pendant des jours, alors qu'un jeton d'accès ne devrait durer que quelques minutes, et l'application a donc besoin d'un jeton de rafraîchissement pour obtenir de nouveaux jetons d'accès en arrière-plan. La plateforme est conçue pour qu'une application qui demande le scope offline_access reçoive un jeton de rafraîchissement hors ligne, distinct de la session d'authentification unique du navigateur et qui ne prend pas fin avec elle. La durée prévue est de 7 jours par défaut, et vous pourrez la porter jusqu'à 30 jours pour chaque application. Vous pourrez ainsi choisir une durée plus courte pour une application qui traite des données sensibles et une durée plus longue pour une application où se reconnecter ne ferait que gêner.
Le jeton de rafraîchissement hors ligne est prévu pour être renouvelé à chaque utilisation : chaque rafraîchissement renvoie un nouveau jeton et retire l'ancien. Si un ancien jeton est présenté de nouveau, la détection de réutilisation est conçue pour y voir le signe d'une copie, et une copie volée cesse d'être utile. Le jeton est aussi prévu pour être révoqué quand l'utilisateur se déconnecte de cette application, quand votre backend appelle le point de révocation ou quand un administrateur le révoque, et se déconnecter d'une application doit ne mettre fin qu'au jeton de cette application, pour que l'utilisateur reste connecté à vos autres applications.
Passkeys et authentification multifacteur sur téléphone
Une passkey est un identifiant de connexion stocké sur l'appareil de l'utilisateur et déverrouillé par une empreinte digitale, une reconnaissance faciale ou le code de l'appareil, si bien qu'il n'y a aucun mot de passe à saisir ni à hameçonner. Les téléphones se prêtent bien aux passkeys, car la clé se trouve sur l'appareil que l'utilisateur tient déjà en main et le système d'exploitation peut la synchroniser avec ses autres appareils. Comme votre application se connecte par le navigateur système, c'est le système d'exploitation qui affiche la demande de passkey, et votre application n'a besoin d'aucun code propre aux passkeys.
Les passkeys et l'authentification multifacteur figurent au plan de la plateforme, avec une vérification des mots de passe compromis pour les utilisateurs qui se connectent encore par mot de passe. Chaque environnement de votre application, comme la production et la préproduction, est un tenant avec ses propres utilisateurs et son adresse de connexion, si bien que les comptes de test ne se mélangent jamais aux vrais. Nous ne présentons une fonctionnalité comme disponible qu'une fois livrée, et une démo vous montre lesquelles votre application mobile peut utiliser aujourd'hui.
Questions fréquentes
Une application mobile doit-elle utiliser une web view intégrée pour la connexion ?
Non. Une web view intégrée permet à l'application de lire ce que saisit l'utilisateur, et elle ne partage pas la session ni les passkeys enregistrées du navigateur. Utilisez le navigateur système ou l'onglet de navigateur intégré du système d'exploitation, avec le flux authorization code et PKCE.
Combien de temps un utilisateur reste-t-il connecté à une application mobile ?
Sur la plateforme, aussi longtemps que le jeton de rafraîchissement hors ligne de l'application est valable, avec une durée prévue de 7 jours par défaut et jusqu'à 30 jours si vous le réglez ainsi pour l'application. Une déconnexion de l'application, un appel de révocation ou un administrateur doit y mettre fin plus tôt.
Découvrez Skycloak Platform par vous-même
Réservez une démo : nous vous présentons la plateforme en partant de vos propres parcours de connexion.