Créer l’API
- Name : un nom convivial pour l’API. N’affecte aucune fonctionnalité.
- Identifier : un identifiant unique pour l’API. Nous vous recommandons d’utiliser une URL, mais notez qu’il n’est pas nécessaire qu’elle soit accessible publiquement : Auth0 n’effectuera aucune requête vers votre API. Cette valeur ne peut pas être modifiée par la suite.
- : l’algorithme utilisé pour signer les jetons. Les valeurs possibles sont
HS256etRS256. Si vous sélectionnez RS256, le jeton sera signé avec la clé privée du tenant. Pour en savoir plus sur les algorithmes de signature, consultez Algorithmes de signature.

Algorithmes de signature
La signature fait partie d’un JWT. Si vous ne connaissez pas bien la structure d’un JWT, veuillez consulter Structure du JSON Web Token.
HS256 ou RS256.
- RS256 est un algorithme asymétrique, ce qui signifie qu’il y a deux clés : une publique et une privée (secrète). Auth0 possède la clé secrète, qui sert à générer la signature, et le consommateur du JWT possède la clé publique, qui sert à valider la signature.
- HS256 est un algorithme symétrique, ce qui signifie qu’il n’y a qu’une seule clé secrète, partagée entre les deux parties. La même clé sert à la fois à générer la signature et à la valider. Il faut donc prendre des précautions particulières pour que la clé demeure confidentielle.
- Avec RS256, vous avez l’assurance que seul le détenteur de la clé privée (Auth0) peut signer des jetons, tandis que n’importe qui peut vérifier si le jeton est valide à l’aide de la clé publique.
- Avec HS256, si la clé privée est compromise, vous devrez redéployer l’API avec le nouveau secret. Avec RS256, vous pouvez demander un jeton valide pour plusieurs audiences.
- Avec RS256, vous pouvez effectuer une rotation des clés sans avoir à redéployer l’API avec le nouveau secret.
Pour un aperçu plus détaillé des algorithmes de signature JWT, consultez : Vue d’ensemble des algorithmes de signature de JSON Web Token (JWT).
Configurer les Permissions
read:timesheets, create:timesheets, delete:timesheets, approve:timesheets.

Créer l’application
Timesheets Mobile) et sélectionnez Native App comme type.
Cliquez sur Create.
Vous devrez vous assurer que l’Authorization Extension est installée dans votre tenant. Vous pouvez consulter la documentation de l’Authorization Extension pour savoir comment procéder.
Définir les permissions
Définir des rôles
delete:timesheets, create:timesheets et read:timesheets. Cliquez sur Enregistrer.
Ensuite, suivez le même processus pour créer le rôle Manager et assurez-vous d’avoir sélectionné toutes les permissions :

Attribuer des utilisateurs à des rôles
Créer une Rule pour valider les scopes du jeton
action:area ou delete:timesheets) qui sont valides selon les permissions de l’utilisateur. Une fois terminé, vous pouvez cliquer sur le bouton Enregistrer.
Les Rules s’exécutent dans l’ordre où elles sont affichées sur la page Rules; assurez-vous donc que la nouvelle règle que vous avez créée est placée sous la règle de l’Authorization Extension, pour qu’elle s’exécute après la règle Authorization Extension.
TUTORIEL PRÉCÉDENT 1. Aperçu de la solution
TUTORIEL SUIVANT 3. API + mise en œuvre mobile