Aperçu de solution (SPA + API)

Aperçu de solution pour le scénario d’architecture 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.

​

Authentification et autorisation de l’API

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.

Qu’est-ce qu’un jeton d’accès?

Un jeton d’accès (aussi désigné comme  access_token) est une chaîne opaque représentant une autorisation envoyée à l’application. Il peut désigner un identifiant utilisé pour récupérer les informations d’autorisation ou contenir lui-même les informations d’autorisation (par exemple, l’identité de l’utilisateur, les autorisations, etc.).

Il est fréquent que les jetons d’accès soient implémentés comme des Jetons Web JSON.

Pour en savoir plus sur les jetons d’accès Auth0, consultez Jeton d’accès.

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.

Que sont les permissions?

Chaque jeton d’accès peut inclure une liste de permissions qui ont été autorisées au client. Lorsqu’un client s’authentifie avec Auth0, cela spécifiera la liste des permissions qu’il demande. Si ces permissions sont autorisées, le jeton d’accès en contiendra la liste.

Par exemple, l’API de feuille de temps peut accepter quatre niveaux d’autorisation différents : lecture des feuilles de temps (permission read:timesheets), création des feuilles de temps (permission create:timesheets), suppression des feuilles de temps (permission delete:timesheets) et approbation des feuilles de temps (permission approve:timesheets).

Lorsqu’un client demande à l’API de créer une nouvelle entrée de feuille de temps, le jeton d’accès doit contenir la permission create:timesheets . D’une manière similaire, afin de supprimer des feuilles de temps existantes, le jeton d’accès doit contenir la permission delete:timesheets .

Pour en savoir plus sur les permissions, consultez Permissions.

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.

Rôles OAuth

Dans tout flux OAuth 2.0, nous pouvons identifier les rôles suivants :

• Resource Owner (Propriétaire de ressource) : l’entité qui peut donner accès à la ressource protégée. Il s’agit habituellement de l’utilisateur final.
• Resource Server (Serveur de ressources) : serveur hébergeant les ressources protégées. Il s’agit de l’API à laquelle vous souhaitez accéder.
• Client : une application demandant l’accès à une ressource protégée au nom du propriétaire de ressource.
• Authorization Server (Serveur d’autorisation) : le serveur qui authentifie le propriétaire de ressource, et émet les jetons d’accès afin de fournir l’autorisation adéquate. Dans ce cas, l’Authentication API Auth0.

Les types d’autorisations (ou flux) determinent comment ces participants interagiront pour autoriser un accès limité des applications client aux API que vous créez. En conséquence, l’application obtiendra un jeton d’accès qui peut être utilisé pour appeler l’API au nom de l’utilisateur.

​

Proof Key for Code Exchange (PKCE)

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.

Si la Rotation des jetons d’actualisation est activée, un nouveau jeton d’actualisation est généré pour chaque demande et émis en même temps que le jeton d’accès. Lorsqu’un jeton d’actualisation est échangé, le jeton d’actualisation précédent est invalidé, mais les informations concernant leur relation sont conservées par le serveur d’autorisations.

​

Authorization Extension

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.