Aperçu de solution (SPA + API)

Afin de s’assurer que seuls les utilisateurs et applications autorisés ont accès à l’API des feuilles de temps, ExampleCo a décidé d’utiliser le cadre d’applications Authorization OAuth 2.0. Le cadre d’applications offre la flexibilité que l’entreprise souhaite puisque les différentes autorisations peuvent lui permettre d’autoriser facilement les différents types d’applications qui ont besoin de communiquer avec l’API des feuilles de temps.

Une API est un moyen d’exposer les fonctionnalités de votre application à d’autres applications. Une application peut effectuer une demande en envoyant un message à un point de terminaison sur une API et recevoir des informations en réponse.

Un point de terminaison d’API peut être sécurisé ou non. Dans notre cas, étant donné que les feuilles de temps sont des informations confidentielles qui affectent les avis et les paiements, il est important de garantir que seuls les utilisateurs et les applications autorisés peuvent appeler les points de terminaison de notre API. Quand une application client veut accéder à des points de terminaison protégés sur une API, elle doit présenter un jeton d’accès pour prouver qu’elle dispose des autorisations requises pour effectuer l’appel au point de terminaison.

Un jeton d’accès est obtenu en authentifiant l’utilisateur auprès d’un serveur d’autorisation et l’utilisateur peut alors, à son tour, autoriser l’application à accéder à l’API en son nom.

Une API peut appliquer un contrôle précis sur qui peut accéder aux différents points de terminaison exposés par l’API. Ces autorisations sont exprimées sous la forme de permissions.

Quand un utilisateur autorise une application client, l’application peut aussi indiquer les autorisations dont elle a besoin. L’utilisateur est ensuite autorisé à examiner et à accorder ces autorisations. Ces autorisations sont ensuite incluses dans le jeton d’accès dans le cadre de la demande de scope.

Par la suite, quand le client transmet le jeton d’accès durant l’envoi de demandes à l’API, l’API peut inspecter la demande de scope pour s’assurer que les autorisations requises ont été accordées afin d’appeler le point de terminaison de l’API particulier.

En utilisant le cadre d’applications Authorization OAuth 2.0, vous pouvez donner à vos propres applications ou à des applications tierces parties un accès limité à vos API au nom de l’application elle-même. En utilisant Auth0, vous pouvez facilement prendre en charge différents flux dans vos API sans se soucier de la spécification OAuth 2.0/OpenID Connect (OIDC) ou des nombreux autres aspects techniques de l’autorisation d’API.

OAuth 2.0 fournit plusieurs types d’autorisation pour différents cas d’utilisation. Dans ce cas d’utilisation particulier, nous voulons accéder à l’API à partir d’une application mobile, qui utilisera le Flux de code d’autorisation avec Proof Key for Code Exchange (PKCE) pour ce faire.

La Proof Key for Code Exchange (PKCE) est définie dans RFC 7636; il s’agit d’une technique utilisée pour atténuer une attaque d’interception de code d’autorisation dans laquelle une personne malveillante peut intercepter le authorization_code retourné par Auth0 et l’échanger contre un jeton d’accès (et éventuellement un jeton d’actualisation).

Avec PKCE, l’application crée, pour chaque demande d’autorisation, une clé cryptographiquement aléatoire appelée code_verifier et sa valeur transformée appelée code_challenge, qui est envoyé vers Auth0 pour obtenir le authorization_code. Quand l’application reçoit le authorization_code, elle enverra le code et le code_verifier au point de terminaison du jeton d’Auth0 pour les échanger contre les jetons demandés.

1. L’application initie le flux et redirige l’utilisateur vers Auth0 (spécifiquement vers le point de terminaison /authorize), envoyant les paramètres code_challenge et code_challenge_method. L’application génère également le code_verifier à envoyer après une authentification réussie.

2. Auth0 authentifie l’utilisateur.

3. Une fois l’utilisateur authentifié, Auth0 le redirige vers l’application avec un authorization_code dans le lien de demande.

4. L’application envoie le code_verifier et le redirect_uri avec le client_id vers Auth0. Cela se fait en utilisant le point de terminaison /oauth/token.

5. Auth0 valide cette information et retourne un jeton d’accès (et éventuellement un jeton d’actualisation).

6. L’application peut utiliser le jeton d’accès pour appeler l’API au nom de l’utilisateur.

Auth0 Authorization Extension vous permet de configurer les rôles, les groupes et les autorisations, et de les attribuer aux utilisateurs.

• Les autorisations sont des actions que quelqu’un peut effectuer. Pour les besoins commerciaux de ExampleCo, nous allons configurer quatre autorisations : lire, créer, supprimer et approuver les feuilles de temps.

• Les rôles sont des collections d’autorisations. L’application de feuilles de temps d’ExampleCo sera utilisée par deux types d’utilisateurs (employés et gestionnaires), avec des autorisations différentes chacun, nous allons donc configurer deux rôles : employé et gestionnaire.

Étant donné que cela couvre notre analyse de rentabilité, nous ne créerons aucun groupe.

Authorization Extension créera une règle qui lira les rôles, les groupes et les autorisations attribués à un utilisateur et ajoutera ces informations au profil utilisateur pendant le flux d’authentification. Nous pouvons ensuite utiliser ces informations pour garantir que le jeton d’accès émis à un utilisateur contient uniquement les permissions autorisées. Nous pouvons ensuite procéder à la personnalisation de notre application, comme la désactivation de la fonctionnalité Approuver les feuilles de temps si l’utilisateur n’a pas l’autorisation requise pour le faire.