Les applications Wear OS peuvent s'exécuter de manière autonome sans application associée. Cela signifie qu'une application Wear OS doit gérer elle-même l'authentification lorsqu'elle accède aux données depuis Internet. Le petit écran et les fonctionnalités de saisie réduites des montres connectées limitent les options d'authentification qu'une application Wear OS peut utiliser.
Ce guide fournit des instructions sur la méthode d'authentification recommandée pour les applications Wear OS, à savoir le Gestionnaire d'identifiants.
Pour en savoir plus sur la manière de concevoir une bonne expérience de connexion, consultez le guide de connexion de l'expérience utilisateur.
Considérations préliminaires
Avant de commencer votre implémentation, tenez compte des points suivants.
Mode Invité
N'exigez pas l'authentification pour toutes les fonctionnalités. Fournissez plutôt autant de fonctionnalités que possible à l'utilisateur, sans qu'il ait à se connecter.
Les utilisateurs peuvent découvrir et installer votre application Wear sans avoir utilisé l'application mobile. Ils peuvent donc ne pas avoir de compte et ne pas savoir quelles fonctionnalités sont disponibles. Assurez-vous que le mode Invité permette à l'utilisateur de découvrir avec précision les fonctionnalités de votre application.
Certains appareils peuvent rester déverrouillés plus longtemps
Sur les appareils compatibles équipés de Wear OS 5 ou version ultérieure, le système détecte si l'utilisateur porte l'appareil au poignet. Si l'utilisateur désactive la détection du poignet, puis retire l'appareil de son poignet, le système maintient l'appareil déverrouillé pendant une période plus longue que d'habitude.
Si votre application nécessite un niveau de sécurité plus élevé (par exemple, lors de l'affichage de données potentiellement sensibles ou privées), vérifiez d'abord si la détection du poignet est activée:
val wristDetectionEnabled =
isWristDetectionAutoLockingEnabled(applicationContext)
Si la valeur renvoyée par cette méthode est false, invitez l'utilisateur à se connecter à un compte dans votre application avant d'afficher du contenu spécifique à l'utilisateur.
Gestionnaire d'identifiants
Le Gestionnaire d'identifiants est l'API recommandée pour l'authentification sur Wear OS. Il offre un environnement plus sécurisé pour que les utilisateurs se connectent aux applications Wear OS dans un environnement autonome, sans avoir besoin d'un téléphone associé connecté et sans avoir à mémoriser leur mot de passe.
Ce document décrit les informations dont les développeurs ont besoin pour implémenter une solution de Gestionnaire d'identifiants avec les mécanismes d'authentification standards qu'il héberge, à savoir:
- Clés d'accès
- Mots de passe
- Identités fédérées (par exemple, Se connecter avec Google)
Ce guide explique également comment migrer les autres méthodes d'authentification Wear OS acceptées (Partage de jetons de couche de données et OAuth) en tant que sauvegardes du Gestionnaire d'identifiants, ainsi que des instructions spéciales pour gérer la transition du bouton de connexion Google autonome, désormais obsolète, vers la version intégrée du Gestionnaire d'identifiants.
Clés d'accès sur Wear OS
Les développeurs sont vivement encouragés à implémenter des clés d'accès dans leurs implémentations du Gestionnaire d'identifiants Wear OS. Les clés d'accès sont la nouvelle norme du secteur pour l'authentification des utilisateurs finaux. Elles présentent plusieurs avantages importants pour les utilisateurs.
Les clés d'accès sont plus simples
- Les utilisateurs peuvent sélectionner un compte avec lequel se connecter. Ils n'ont pas besoin de saisir de nom d'utilisateur.
- Les utilisateurs peuvent s'authentifier à l'aide du verrouillage de l'écran de l'appareil.
- Une fois qu'une clé d'accès a été créée et enregistrée, l'utilisateur peut passer facilement à un nouvel appareil et l'utiliser immédiatement sans avoir à le réenregistrer.
Les clés d'accès sont plus sûres
- Les développeurs n'enregistrent qu'une clé publique sur le serveur au lieu d'un mot de passe. Cela signifie qu'il est beaucoup moins intéressant pour un pirate informatique de pirater des serveurs et que le nettoyage est beaucoup moins important en cas de violation.
- Les clés d'accès offrent une protection anti-hameçonnage. Les clés d'accès ne fonctionnent que pour les applications et les sites Web enregistrés. Un utilisateur ne peut pas être incité à s'authentifier sur un site trompeur, car le navigateur ou l'OS gère la validation.
- Les clés d'accès réduisent le besoin d'envoyer des SMS, ce qui rend l'authentification plus rentable.
Implémenter des clés d'accès
Inclut la configuration et des conseils pour tous les types d'implémentations.
Configuration
Définissez le niveau d'API cible sur 35 dans le fichier build.gradle de votre module d'application:
android { defaultConfig { targetSdkVersion(35) } }Ajoutez les lignes suivantes au fichier build.gradle de votre application ou de votre module, en utilisant la dernière version stable de la référence Versions
androidx.credentials.androidx.credentials:credentials:1.5.0 androidx.credentials:credentials-play-services-auth:1.5.0
Méthodes d'authentification intégrées
Étant donné que le Gestionnaire d'identifiants est une API unifiée, les étapes d'implémentation pour Wear OS sont les mêmes que pour tout autre type d'appareil.
Utilisez les instructions pour les appareils mobiles pour vous lancer et implémenter la prise en charge des clés d'accès et des mots de passe.
La procédure d'ajout de la fonctionnalité Se connecter avec Google au Gestionnaire d'identifiants est destinée au développement mobile, mais elle est identique sur Wear OS. Consultez la section Passer de l'ancienne fonctionnalité Se connecter avec Google pour connaître les considérations particulières dans ce cas.
Notez que, comme vous ne pouvez pas créer d'identifiants sur Wear OS, vous n'avez pas besoin d'implémenter les méthodes de création d'identifiants mentionnées dans les instructions pour les mobiles.
Méthodes d'authentification de secours
Il existe deux autres méthodes d'authentification acceptables pour les applications Wear OS: OAuth 2.0 (les deux variantes) et le partage de la couche de données du jeton d'authentification mobile. Bien que ces méthodes n'aient pas de points d'intégration dans l'API Gestionnaire d'identifiants, elles peuvent être incluses dans votre flux d'expérience utilisateur du Gestionnaire d'identifiants en tant que solutions de secours au cas où les utilisateurs fermeraient l'écran du Gestionnaire d'identifiants.
Pour gérer l'action de l'utilisateur consistant à fermer l'écran du Gestionnaire d'identifiants, interceptez un NoCredentialException dans le cadre de votre logique GetCredential et accédez à votre propre UI d'authentification personnalisée.
yourCoroutineScope.launch {
try {
val response = credentialManager.getCredential(activity, request)
signInWithCredential(response.credential)
} catch (e: GetCredentialCancellationException) {
navigateToFallbackAuthMethods()
}
}
Votre UI d'authentification personnalisée peut ensuite fournir l'une des autres méthodes d'authentification acceptables décrites dans le guide UX de connexion.
Partage de jetons de couche de données
L'application mobile associée peut transférer de manière sécurisée les données d'authentification vers l'application Wear OS à l'aide de l'API Wearable Data Layer. Transférez les identifiants sous forme de messages ou de données.
Ce type d'authentification ne nécessite généralement aucune action de la part de l'utilisateur. Toutefois, évitez d'effectuer l'authentification sans informer l'utilisateur qu'il est en train de se connecter. Vous pouvez informer l'utilisateur que son compte est en cours de transfert depuis l'application mobile en lui affichant un écran qu'il pourra fermer ensuite.
Important:Votre application Wear OS doit proposer au moins une autre méthode d'authentification, car cette option ne fonctionne que sur les montres associées à un appareil Android sur lequel l'application mobile correspondante est installée. Fournissez une autre méthode d'authentification pour les utilisateurs qui ne disposent pas de l'application mobile correspondante ou pour les utilisateurs dont l'appareil Wear OS est associé à un appareil iOS.
Transmettez des jetons à l'aide de la couche de données de l'application mobile, comme illustré dans l'exemple suivant:
val token = "..." // Auth token to transmit to the Wear OS device.
val dataClient: DataClient = Wearable.getDataClient(context)
val putDataReq: PutDataRequest = PutDataMapRequest.create("/auth").run {
dataMap.putString("token", token)
asPutDataRequest()
}
val putDataTask: Task<DataItem> = dataClient.putDataItem(putDataReq)
Écoutez les événements de changement des données dans l'application Wear OS, comme illustré dans l'exemple suivant:
val dataClient: DataClient = Wearable.getDataClient(context)
dataClient.addListener{ dataEvents ->
dataEvents.forEach { event ->
if (event.type == DataEvent.TYPE_CHANGED) {
val dataItemPath = event.dataItem.uri.path ?: ""
if (dataItemPath.startsWith("/auth")) {
val token = DataMapItem.fromDataItem(event.dataItem).dataMap.getString("token")
// Display an interstitial screen to notify the user that
// they're being signed in.
// Then, store the token and use it in network requests.
}
}
}
}
Pour en savoir plus sur l'utilisation de Wearable Data Layer, consultez la page Envoyer et synchroniser des données sur Wear OS.
Utiliser OAuth 2.0
Wear OS est compatible avec deux flux OAuth 2.0, décrits dans les sections ci-dessous :
- Octroi du code d'autorisation avec PKCE (Proof Key for Code Exchange), comme défini dans la RFC 7636
- Autorisation via un appareil (DAG), comme défini dans la RFC 8628
Clé de vérification pour l'échange de code (PKCE)
Pour utiliser efficacement la PKCE, utilisez RemoteAuthClient.
Ensuite, pour envoyer une requête d'authentification à un fournisseur OAuth à partir de votre application Wear OS, créez un objet OAuthRequest. Cet objet se compose d'une URL vers votre point de terminaison OAuth permettant d'obtenir un jeton et un objet CodeChallenge.
Le code suivant montre un exemple de création d'une requête d'authentification :
val request = OAuthRequest.Builder(this.applicationContext)
.setAuthProviderUrl(Uri.parse("https://...."))
.setClientId(clientId)
.setCodeChallenge(codeChallenge)
.build()
Après avoir créé la requête d'authentification, envoyez-la à l'application associée à l'aide de la méthode sendAuthorizationRequest():
val client = RemoteAuthClient.create(this)
client.sendAuthorizationRequest(request,
{ command -> command?.run() },
object : RemoteAuthClient.Callback() {
override fun onAuthorizationResponse(
request: OAuthRequest,
response: OAuthResponse
) {
// Extract the token from the response, store it, and use it in
// network requests.
}
override fun onAuthorizationError(errorCode: Int) {
// Handle any errors.
}
}
)
Cette requête déclenche un appel à l'application associée, qui présente ensuite une interface d'autorisation dans un navigateur Web sur le téléphone mobile de l'utilisateur. Le fournisseur OAuth 2.0 authentifie l'utilisateur et obtient son consentement pour les autorisations demandées. La réponse est envoyée à l'URL de redirection générée automatiquement.
Après l'échec ou la réussite de l'autorisation, le serveur OAuth 2.0 redirige vers l'URL spécifiée dans la requête. Si l'utilisateur approuve la demande d'accès, la réponse contient un code d'autorisation. Si l'utilisateur n'approuve pas la requête, la réponse contient un message d'erreur.
La réponse se présente sous la forme d'une chaîne de requête et ressemble à l'un des exemples suivants:
https://wear.googleapis.com/3p_auth/com.your.package.name?code=xyz
https://wear.googleapis-cn.com/3p_auth/com.your.package.name?code=xyz
Une page qui redirige l'utilisateur vers l'application associée se charge. Celle-ci vérifie l'URL de la réponse et transmet la réponse à votre application Wear OS à l'aide de l'API onAuthorizationResponse.
L'application de la montre peut alors échanger le code d'autorisation contre un jeton d'accès.
Autorisation via un appareil
Avec l'autorisation via un appareil, l'utilisateur ouvre l'URI de vérification sur un autre appareil. Le serveur d'autorisation lui demande ensuite d'approuver ou de refuser la demande.
Pour faciliter ce processus, utilisez un RemoteActivityHelper pour ouvrir une page Web sur l'appareil mobile associé de l'utilisateur, comme illustré dans l'exemple suivant:
// Request access from the authorization server and receive Device Authorization
// Response.
val verificationUri = "..." // Extracted from the Device Authorization Response.
RemoteActivityHelper.startRemoteActivity(
this,
Intent(Intent.ACTION_VIEW)
.addCategory(Intent.CATEGORY_BROWSABLE)
.setData(Uri.parse(verificationUri)),
null
)
// Poll the authorization server to find out if the user completed the user
// authorization step on their mobile device.
Si vous disposez d'une application iOS, utilisez des liens universels pour intercepter cet intent dans votre application au lieu de compter sur le navigateur pour autoriser le jeton.
Abandon de l'ancienne fonctionnalité Se connecter avec Google
Le Gestionnaire d'identifiants dispose d'un point d'intégration dédié pour un bouton "Se connecter avec Google". Auparavant, ce bouton pouvait être ajouté n'importe où dans l'expérience utilisateur d'authentification d'une application. Toutefois, avec son inclusion dans le Gestionnaire d'identifiants, l'ancienne option est désormais obsolète.
// Define a basic SDK check.
fun isCredentialManagerAvailable(): Boolean {
return android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.VANILLA_ICE_CREAM
}
// Elsewhere in the code, use it to selectively disable the legacy option.
Button(
onClick = {
if (isCredentialManagerAvailable()) {
Log.w(TAG, "Devices on API level 35 or higher should use
Credential Manager for Sign in with Google")
} else {
navigateToSignInWithGoogle()
}},
enabled = !isCredentialManagerAvailable(),
label = { Text(text = stringResource(R.string.sign_in_with_google)) },
secondaryLabel = { Text(text = "Disabled on API level 35+")
}
)