> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-fix-docs-5528-php-updates.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Configuration Auth0 (Applications mobiles + API)
> Configuration Auth0 pour le scénario d’architecture mobile + API
Dans cette section, nous passerons en revue toutes les configurations que nous devons appliquer à l’[Auth0 Dashboard](https://manage.auth0.com/#).
## Création de l’API
Cliquez sur l’[option de menu API](https://manage.auth0.com/#/apis) sur la gauche, et cliquez sur la touche Créer une API.
Vous devrez fournir les informations suivantes pour votre API :
* **Nom** : un nom convivial pour l’API. N’affecte aucune fonctionnalité.
* **Identifiant** : identifiant unique pour l’API. Nous recommandons d’utiliser une URL mais il n’est pas nécessaire qu’elle soit accessible au public, Auth0 n’appellera pas votre API. Cette valeur ne peut pas être modifiée par la suite.
* **Algorithme de signature** : l’algorithme avec lequel les jetons sont signés. Les valeurs possibles sont `HS256` et `RS256`. Si vous sélectionnez RS256 le jeton sera signé avec la clé privée de votre locataire. Pour en savoir plus sur les algorithmes de signature, consultez [Algorithmes de signature](/docs/fr-ca/get-started/applications/signing-algorithms).
Remplissez les informations requises et cliquez sur la touche **Créer**.
#### Algorithmes de signature
Lorsque vous créez une API devez sélectionner l’algorithme avec lequel vos jetons seront signés. La signature est utilisée pour vérifier que l’expéditeur du jeton Web JSON (JWT) est bien celui qu’il prétend être et pour s’assurer que le message n’a pas été modifié en cours de route.
La signature fait partie d’un JWT. Si vous n’êtes pas familier avec la structure des JWT, veuillez consulter [Structure du jeton Web JSON](/docs/fr-ca/secure/tokens/json-web-tokens/json-web-token-structure).
Pour créer la signature, vous devez prendre l’en-tête encodé, la charge utile encodée, un secret, l’algorithme spécifié dans l’en-tête et signer le tout. Cet algorithme, qui fait partie de l’en-tête JWT, est celui que vous sélectionnez pour votre API : `HS256` ou `RS256`.
* **RS256** est un [algorithme asymétrique](https://en.wikipedia.org/wiki/Public-key_cryptography), ce qui signifie qu’il y a deux clés : une clé publique et une clé privée qui doit être gardée secrète. Auth0 possède la clé secrète, qui est utilisée pour générer la signature, et le consommateur du JWT possède la clé publique, qui est utilisée pour valider la signature.
* **HS256** est un [algorithme symétrique](https://en.wikipedia.org/wiki/Symmetric-key_algorithm) ce qui signifie qu’il n’y a qu’une seule clé secrète, partagée entre les deux parties. La même clé est utilisée à la fois pour générer la signature et pour la valider. Des précautions particulières doivent être prises pour que la clé reste confidentielle.
La pratique la plus sûre, et notre recommandation, est d’utiliser **RS256**. Voici quelques raisons :
* Avec RS256, vous êtes sûr que seul le détenteur de la clé privée (Auth0) peut signer les jetons, tandis que n’importe qui peut vérifier si le jeton est valide à l’aide de la clé publique.
* Dans un contexte lié à HS256, si la clé privée est compromise, vous allez devoir déployer à nouveau l’API avec le nouveau secret. Avec RS256 pouvez demander un jeton valide pour différentes audiences.
* Avec RS256 vous pouvez mettre en œuvre la rotation des clés sans avoir à redéployer l’API avec le nouveau secret.
Pour une présentation plus détaillée des algorithmes de signature des JWT, consultez : [Présentation des algorithmes de signature des jetons Web JSON (JWT)](https://auth0.com/blog/json-web-token-signing-algorithms-overview/).
### Configuration des permissions
Une fois que l’application a été créée, vous devez configurer les permissions que les applications peuvent demander pendant l’autorisation.
Dans les paramètres de votre API, rendez-vous dans l’onglet **Permissions**. Dans cette section, vous pouvez ajouter les quatre permissions mentionnés précédemment : `read:timesheets`, `create:timesheets`, `delete:timesheets`, et `approve:timesheets`.
## Créer l’application
Il existe quatre types d’applications dans Auth0 : **Native App (Applications natives)** (utilisées pour les applications mobiles ou de bureau), **Single-Page Web App (Applications à page unique)**, **Regular Web App (Applications Web régulières)**, et **Machine to Machine App (Applications de communication entre machines** (utilisées par les CLI, les démons ou les services s’exécutant sur votre système dorsal). Pour ce scénario, nous voulons créer une nouvelle application pour notre application mobile, nous utiliserons donc une application de type Native.
Pour créer une nouvelle application, accédez au [tableau de bord](https://manage.auth0.com/#) et cliquez sur l’option de menu [Applications](https://manage.auth0.com/#/applications) à gauche. Cliquez sur la touche **+ Créer une application**.
Définissez un nom pour votre application (nous utiliserons `Timesheets Mobile`) et sélectionnez `Native App` comme type.
Cliquez sur **Créer**.
## Configure the Authorization Extension (Configurer l’extension d’autorisation)
Vous devez vous assurer que Authorization Extension est installée pour votre locataire. Vous pouvez vous référer à la [documentation relative à Authorization Extension](/docs/fr-ca/customize/extensions/authorization-extension) pour plus de détails sur la manière de procéder.
### Définir les autorisations
Vous devrez définir des autorisations qui correspondent aux permissions que vous avez déjà définies. Dans Authorization Extension, cliquez sur l’onglet Autorisations, puis sur la touche **Create Permission (Créer une autorisation)**. Dans la boîte de dialogue, saisissez les détails de chaque autorisation. Veillez à ce que le nom de l’autorisation soit exactement le même que celui de la permission correspondante :
Créez les autorisations pour toutes les permissions restantes :
### Définir les rôles
Allez dans l’onglet Rôles et créez deux rôles. Cliquez sur la touche **Créer un rôle** et sélectionnez l’application **Monopage Feuille de temps**. Donnez au rôle un nom et une description d’employé, et sélectionnez les autorisations `delete:timesheets`, `create:timesheets` and `read:timesheets`. Cliquez sur **Enregistrer**.
Ensuite, suivez le même processus pour créer un rôle de **Gestionnaire** et assurez-vous que vous avez sélectionné toutes les autorisations :
### Attribuer des utilisateurs aux rôles
Vous devrez attribuer à tous les utilisateurs le rôle de gestionnaire ou d’utilisateur. Vous pouvez le faire en allant dans l’onglet Utilisateurs d’Authorization Extension et en sélectionnant un utilisateur. Dans l’écran d’informations de l’utilisateur, allez dans l’onglet Rôles. Vous pouvez ajouter un rôle à l’utilisateur en cliquant sur la touche **Ajouter un rôle à l’utilisateur** en sélectionnant le rôle approprié pour l’utilisateur.
### Configuration d’Authorization Extension
Vous devrez également vous assurer que la règle pour Authorization Extension est publiée. Vous pouvez le faire en cliquant sur votre avatar d’utilisateur en haut à droite d’Authorization Extension, et en sélectionnant l’option **Configuration** :
Assurez-vous que vous avez activé les **Autorisations**, puis cliquez sur la touche **Publier la règle**.
### Créer une règle pour valider les permissions des jetons
La dernière étape de ce processus consiste à créer une règle qui validera que les permissions contenues dans un jeton d’accès sont valides en fonction des autorisations attribuées à l’utilisateur. Toutes les permissions qui ne sont pas valables pour un utilisateur doivent être supprimées du jeton d’accès.
Dans votre Auth0 Dashboard, allez dans l’onglet Règles. Vous devriez voir la règle créée par Authorization Extension.
Cliquez sur la touche **Créer une règle** et sélectionnez le modèle **Règle vide**. Vous pouvez donner un nom à la règle, par exemple **Permissions des jetons d’accès**, puis indiquer le code suivant pour la règle :
```javascript lines theme={null}
function (user, context, callback) {
if (context.clientName !== 'Timesheets SPA') {
return callback(null, user, context);
}
var permissions = user.permissions || [];
var requestedScopes = context.request.body.scope || context.request.query.scope;
var filteredScopes = requestedScopes.split(' ').filter( function(x) {
return x.indexOf(':') < 0;
});
Array.prototype.push.apply(filteredScopes, permissions);
context.accessToken.scope = filteredScopes.join(' ');
callback(null, user, context);
}
```
Le code ci-dessus garantit que tous les jetons d’accès ne contiennent que les champs d’application correctement formatés (p. ex., `action:area` ou `delete:timesheets`) qui sont valides en fonction des permissions de l’utilisateur. Une fois que vous avez terminé, vous pouvez cliquer sur la touche **Enregistrer**.
Les règles s’exécutent dans l’ordre où elles sont affichées sur la page Règles. Par conséquent, veillez à ce que la nouvelle règle que vous avez créée soit placée sous la règle d’Authorization Extension, afin qu’elle s’exécute après la règle d’Authorization Extension.
TUTORIEL PRÉCÉDENT [1. Aperçu de la solution](/docs/fr-ca/get-started/architecture-scenarios/mobile-api/part-1)
TUTORIEL SUIVANT [3. API + Implémentation mobile](/docs/fr-ca/get-started/architecture-scenarios/mobile-api/api-implementation-nodejs)