Créer l’API
- Nom : un nom convivial pour l’API. N’affecte aucune fonctionnalité.
- Identifiant : 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’appellera jamais votre API. Cette valeur ne peut pas être modifiée par la suite.
- : l’algorithme utilisé pour signer les jetons. Les valeurs disponibles sont
HS256etRS256. Si vous sélectionnez RS256, le jeton sera signé avec la clé privée du locataire. Pour en savoir plus sur les algorithmes de signature, consultez Algorithmes de signature.

Algorithmes de signature
La signature fait partie d’un JWT. Si la structure d’un JWT ne vous est pas familière, consultez Structure d’un 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 détient la clé secrète, qui sert à générer la signature, et le consommateur du JWT détient 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. Des précautions particulières doivent être prises 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 les 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 mettre en œuvre 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 : Présentation des algorithmes de signature JSON Web Token (JWT).
Configurer les autorisations
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 devez vous assurer que l’extension Authorization est installée pour votre locataire. Consultez la documentation de l’extension Authorization pour savoir comment procéder.
Définir les autorisations
Définir des rôles
delete:timesheets, create:timesheets et read:timesheets. Cliquez sur Save.
Ensuite, suivez le même processus pour créer un rôle Manager et assurez-vous d’avoir sélectionné toutes les autorisations :

Attribuer des rôles aux utilisateurs
Créer une Rule pour valider les scopes du jeton
action:area ou delete:timesheets) qui sont valides en fonction des autorisations de l’utilisateur. Une fois que vous avez terminé, vous pouvez cliquer sur le bouton Save.
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, afin qu’elle s’exécute après celle de l’Authorization Extension.
TUTORIEL PRÉCÉDENT 1. Aperçu de la solution
TUTORIEL SUIVANT 3. API + implémentation mobile