Premiers pas
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Présentation
Le protocole et l'API Digital Asset Links permettent à une application ou à un site Web de publier des instructions publiques et vérifiables concernant d'autres applications ou sites Web. Par exemple, un site Web peut déclarer qu'il est associé à une application Android spécifique ou qu'il souhaite partager les identifiants de l'utilisateur avec un autre site Web.
Voici quelques cas d'utilisation possibles de Digital Asset Links:
- Le site Web A déclare que les liens vers son site doivent s'ouvrir dans une application désignée sur les appareils mobiles, si l'application est installée.
- Le site Web A déclare qu'il peut partager ses identifiants utilisateur Chrome avec le site Web B, afin que l'utilisateur n'ait pas à se connecter au site Web B s'il est connecté au site Web A.
- L'application A déclare qu'elle peut partager des paramètres de l'appareil, tels que la position, avec le site B.
Termes clés
- Compte principal:le compte principal correspond à l'application ou au site Web à l'origine de l'instruction. Dans Digital Asset Links, le principal est toujours l'application ou le site Web qui héberge la liste de relevés.
- Liste d'instructions: les instructions sont contenues dans une liste d'instructions contenant une ou plusieurs instructions. Une liste d'instructions est en texte clair et accessible au public, dans un emplacement contrôlé par le compte principal et difficile à spoofing ou à falsifier.
Il peut s'agir d'un fichier autonome ou d'une section d'un autre élément plus volumineux. Par exemple, sur un site Web, il s'agit d'un fichier entier. Dans une application Android, il s'agit d'une section du fichier manifeste de l'application.
Les déclarations peuvent être visualisées et vérifiées par n'importe qui, à l'aide de méthodes non propriétaires. Pour en savoir plus, consultez la documentation concernant la liste d'instructions.
- Instruction : une instruction est une construction JSON très structurée qui se compose d'une relation (ce qu'elle indique à faire, par exemple "Activer le partage d'identifiants") et d'une cible (le site Web ou l'application auquel la relation s'applique). Par conséquent, chaque énoncé est semblable à une phrase, où le principal indique relation concernant cible.
- Consommateur d'instructions:un client d'instructions demande une liste d'instructions à un compte principal, vérifie la présence d'une instruction par rapport à un compte principal donné et, si elle existe, peut effectuer l'action spécifiée. Pour en savoir plus, consultez la documentation relative à l'instruction.
Exemple d'utilisation rapide
Voici un exemple très simplifié illustrant comment le site Web www.example.com peut utiliser Digital Asset Links pour indiquer que tous les liens vers des URL de ce site doivent s'ouvrir dans une application désignée plutôt que dans le navigateur:
- Le site Web www.example.com publie une liste de déclarations à l'adresse https://www.example.com/.well-known/assetlinks.json. Il s'agit du nom et de l'emplacement officiels d'une liste de relevés sur un site. Les listes de relevés à un autre emplacement, ou sous un autre nom, ne sont pas valides pour ce site. Dans notre exemple, la liste d'instructions se compose d'une instruction qui accorde à son application Android l'autorisation d'ouvrir des liens sur son site :
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target" : { "namespace": "android_app", "package_name": "com.example.app",
"sha256_cert_fingerprints": ["hash_of_app_certificate"] }
}]
Une liste d'instructions accepte un tableau d'instructions entre les marques [ ], mais notre exemple de fichier ne contient qu'une seule instruction.
sha256_cert_fingerprints est l'empreinte SHA256 du certificat de signature de votre application.
Pour en savoir plus, consultez la documentation Android App Links.
- L'application Android répertoriée dans l'instruction ci-dessus comporte un filtre d'intent qui spécifie le schéma, l'hôte et le format de chemin des URL qu'elle souhaite gérer: dans ce cas, https://www.example.com. Le filtre d'intent inclut un attribut spécial
android:autoVerify, nouveau sur Android M, qui indique qu'Android doit vérifier l'instruction sur le site Web décrit dans le filtre d'intent lorsque l'application est installée.
- Un utilisateur installe l'application. Android voit le filtre d'intent avec l'attribut
autoVerify et vérifie la présence de la liste d'instructions sur le site spécifié. Le cas échéant, Android vérifie si ce fichier inclut une instruction accordant la gestion des liens à l'application et vérifie l'application par rapport à l'instruction par hachage de certificat. Si tout est correct, Android transmet les intents https://www.example.com à l'application example.com.
- L'utilisateur clique sur un lien vers https://www.example.com/chiots sur son appareil. Ce lien peut se trouver n'importe où: dans un navigateur, dans une suggestion Google Search Appliance ou ailleurs. Android transmet l'intent à l'application example.com.
- L'application example.com reçoit l'intent et choisit de le gérer, en ouvrant la page des chiots dans l'application. Si, pour une raison quelconque, l'application a refusé de gérer le lien ou si l'application n'était pas installée sur l'appareil, le lien aurait été envoyé au prochain gestionnaire d'intent par défaut correspondant à ce modèle d'intent (souvent le navigateur).
Remarques et limites importantes:
- Le protocole n'authentifie pas le compte principal qui effectue l'instruction, mais l'instruction est située dans un emplacement spécifique fortement associé à ce compte principal et sous son contrôle.
- Le protocole n'authentifie pas la cible de l'instruction, mais il permet à l'appelant d'authentifier la cible (par exemple, une instruction identifie les cibles d'applications mobiles par hachage de certificat et nom de package).
- Le protocole n'exécute aucune action d'instruction de manière native. Il permet plutôt d'exposer les instructions, qu'une application consommatrice doit valider avant de décider si elle doit agir et comment. Android M effectue ces étapes de manière native pour vous. Par exemple, si un site Web délègue la gestion des liens à une application spécifique, Android vérifie et valide l'instruction, valide l'application cible, puis propose à l'application de gérer le lien donné.
- Le protocole ne permet pas de faire des déclarations concernant deux tiers: en d'autres termes, le site Web A peut faire une déclaration concernant le site Web B, mais le site Web A ne peut pas faire de déclaration concernant la relation entre le site Web B et le site C. Toutefois, si le site Web B fait confiance au site Web A, il peut vérifier si le site Web A contient une déclaration accordant l'autorisation au site C et décider de mettre en œuvre cette autorisation.
Étapes suivantes
- Vérifiez s'il existe une documentation explicite pour votre cas d'utilisation.
- Découvrez comment créer une déclaration.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2024/06/26 (UTC).
[null,null,["Dernière mise à jour le 2024/06/26 (UTC)."],[[["\u003cp\u003eDigital Asset Links enable apps and websites to make verifiable statements about their relationships with other apps and websites, such as link handling or credential sharing.\u003c/p\u003e\n"],["\u003cp\u003eThese statements are stored in a publicly accessible statement list, typically an "assetlinks.json" file hosted by the app or website making the statement.\u003c/p\u003e\n"],["\u003cp\u003eAndroid M and above automatically uses Digital Asset Links to verify website-to-app associations and direct links to the appropriate app if installed.\u003c/p\u003e\n"],["\u003cp\u003eThe protocol provides a foundation for trust and delegation between digital entities but relies on consumers to validate and act upon the statements.\u003c/p\u003e\n"]]],[],null,["# Getting Started\n\nOverview\n--------\n\nThe Digital Asset Links protocol and API enable an app or website to make public,\nverifiable *statements* about other apps or websites. For example, a website\ncan declare that it is associated with a specific Android app, or it can declare that\nit wants to share user credentials with another website.\n\nHere are some possible uses for Digital Asset Links:\n\n- Website A declares that links to its site should open in a designated app on mobile devices, if the app is installed.\n- Website A declares that it can share its Chrome user credentials with website B so that the user won't have to log in to website B if it is logged into website A.\n- App A declares that it can share device settings, such as location, with website B.\n\n### Key terms\n\n- **Principal:** The principal is the app or website making the statement. In Digital Asset Links, the principal is always the app or website that hosts the statement list.\n- **Statement list** : Statements are contained in a *statement list* that contains one or more statements. A statement list is cleartext and publicly accessible, in a location that is controlled by the principal and difficult to spoof or tamper with. It can be a free-standing file, or a section of another, larger item. For example, on a website, it is an entire file; in an Android app, it is a section in the app manifest. Statements can be viewed and verified by anyone, using non-proprietary methods. [See the statement list documentation for more information](/digital-asset-links/v1/create-statement).\n- **Statement:** A statement is a tightly structured JSON construct that consists of a *relation* (what the statement says to do, for example: Enable sharing credentials) and a *target* (the website or app that the relation applies to). Therefore, each statement is like a sentence, where *principal* says *relation* about *target* . \n- **Statement consumer:** A statement consumer requests a statement list from a principal, checks for the presence of a statement against a given principal, and if it exists, can perform the action specified. [See the statement comsuming documentation for more information](/digital-asset-links/v1/consuming)*.*\n\nQuick usage example\n-------------------\n\nHere's a very simplified example of how the website www.example.com could\nuse Digital Asset Links to specify that any links to URLs in that site should\nopen in a designated app rather than the browser:\n\n1. The website www.example.com publishes a statement list at https://www.example.com/.well-known/assetlinks.json. This is the official name and location for a statement list on a site; statement lists in any other location, or with any other name, are not valid for this site. In our example, the statement list consists of one statement, granting its Android app the permission to open links on its site: \n\n ```\n [{\n \"relation\": [\"delegate_permission/common.handle_all_urls\"],\n \"target\" : { \"namespace\": \"android_app\", \"package_name\": \"com.example.app\",\n \"sha256_cert_fingerprints\": [\"hash_of_app_certificate\"] }\n }]\n ```\n A statement list supports an array of statements within the \\[ \\] marks, but our example file contains only one statement. `sha256_cert_fingerprints` is the SHA256 fingerprints of your app's signing certificate. Find more details in the [Android App Links documentation](https://developer.android.com/training/app-links/verify-android-applinks#web-assoc).\n2. The Android app listed in the statement above has an intent filter that specifies the scheme, host, and path pattern of URLs that it wants to handle: in this case, https://www.example.com. The intent filter includes a special attribute `android:autoVerify`, new to Android M, which indicates that Android should verify the statement on the website described in the intent filter when the app is installed.\n3. A user installs the app. Android sees the intent filter with the `autoVerify` attribute and checks for the presence of the statement list at the specified site; if present, Android checks whether that file includes a statement granting link handling to the app, and verifies the app against the statement by certificate hash. If everything checks out, Android will then forward any https://www.example.com intents to the example.com app.\n4. The user clicks a link to https://www.example.com/puppies on their device. This link could be anywhere: in a browser, in a Google Search Appliance suggestion, or anywhere else. Android forwards the intent to the example.com app.\n5. The example.com app receives the intent and chooses to handle it, opening the puppies page in the app. If for some reason the app had declined to handle the link, or if the app were not on the device, then the link would have been sent to the next default intent handler matching that intent pattern (often the browser).\n\nImportant considerations and limitations:\n-----------------------------------------\n\n- The protocol does not authenticate the principal making the statement, but the statement is located in a specific location strongly associated with the principal, and under control of the principal.\n- The protocol does not authenticate the statement target, but it provides a means for the caller to authenticate the target (for example, a statement identifies mobile app targets by certificate hash and package name).\n- The protocol does not natively perform any statement actions; rather, it enables the ability to expose statements, which a consuming application must validate and then decide whether and how to act upon. Android M natively performs these steps for you; for example, if a website delegates link handling to a specific app, Android checks and verifies the statement, verifies the target app, and then offers the app the option to handle the given link.\n- The protocol does not enable making statements about two third parties: that is, website A can make a statement about website B, but website A cannot make a statement about website B's relationship to website C. However, if website B trusts website A, it can check website A for a statement granting permission to website C, and decide to implement that.\n\nNext steps\n----------\n\n1. [See if there is explicit documentation for your use case.](/digital-asset-links/v1/using)\n2. [Learn about creating a statement.](/digital-asset-links/v1/create-statement)"]]
