Création de l’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
HS256etRS256. 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.

Algorithmes de signature
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.
HS256 ou RS256.
- RS256 est un algorithme asymétrique, 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 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.
- 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).
Configuration des permissions
read:timesheets, create:timesheets, delete:timesheets, et approve:timesheets.

Créer l’application
Timesheets Mobile) et sélectionnez Native App comme type.
Cliquez sur Créer.
Vous devez vous assurer que Authorization Extension est installée pour votre locataire. Vous pouvez vous référer à la documentation relative à Authorization Extension pour plus de détails sur la manière de procéder.
Définir les autorisations
Définir les rôles
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
Créer une règle pour valider les permissions des jetons
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
TUTORIEL SUIVANT 3. API + Implémentation mobile