Aperçu de la solution (SPAs + API)

Aperçu de la solution pour le scénario d’architecture SPAs + API

Afin de s’assurer que seuls les utilisateurs et les applications autorisés peuvent accéder à la Timesheets API, ExampleCo a décidé d’utiliser le cadre d’autorisation OAuth 2.0. Ce cadre offre à l’entreprise la souplesse recherchée, puisque les différents types d’octroi lui permettent d’autoriser facilement les divers types d’applications qui doivent communiquer avec la Timesheets API.

​

Authentification et autorisation de l’API

Une API permet d’exposer les fonctionnalités de votre application à d’autres applications. Une application peut envoyer une requête à un point de terminaison d’une API et recevoir des informations en réponse.

Un point de terminaison d’API peut être sécurisé ou non. Dans notre cas, puisque les feuilles de temps contiennent des renseignements sensibles qui ont une incidence sur les évaluations et les paiements, il est important de s’assurer que seuls les utilisateurs et les applications autorisés peuvent appeler les points de terminaison de notre API. Lorsqu’une application cliente veut accéder à des points de terminaison protégés d’une API, elle doit présenter un jeton d’accès comme preuve qu’elle possède les permissions requises pour effectuer la requête vers le point de terminaison.

Un jeton d’accès est obtenu en authentifiant l’utilisateur auprès d’un serveur d’autorisation, après quoi l’utilisateur peut à 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 appelé access_token) est une chaîne opaque représentant une autorisation accordée à l’application. Il peut s’agir d’un identifiant servant à récupérer l’information d’autorisation, ou encore contenir lui-même l’information d’autorisation (par exemple, l’identité de l’utilisateur, les permissions, etc.) d’une manière vérifiable.

Il est très courant que les jetons d’accès soient mis en œuvre sous forme de JSON Web Tokens.

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

Une API peut appliquer un contrôle granulaire sur les personnes qui peuvent accéder aux différents points de terminaison qu’elle expose. Ces permissions sont exprimées sous forme de portées.

Lorsqu’un utilisateur autorise une application cliente, l’application peut aussi indiquer les permissions dont elle a besoin. L’utilisateur peut alors examiner ces permissions et les accorder. Ces permissions sont ensuite incluses dans le jeton d’accès, dans la revendication scope.

Par la suite, lorsque le client transmet le jeton d’accès en effectuant des requêtes vers l’API, l’API peut inspecter la revendication scope pour s’assurer que les permissions requises ont bien été accordées afin d’appeler le point de terminaison d’API en question.

Que sont les portées ?

Chaque jeton d’accès peut inclure une liste des permissions qui ont été accordées au client. Lorsqu’un client s’authentifie auprès d’Auth0, il précise la liste des portées (ou permissions) qu’il demande. Si ces portées sont autorisées, alors le jeton d’accès contiendra une liste des portées autorisées.

Par exemple, l’API de feuilles de temps peut accepter quatre niveaux d’autorisation différents : la lecture des feuilles de temps (portée read:timesheets), la création de feuilles de temps (portée create:timesheets), la suppression de feuilles de temps (portée delete:timesheets) et l’approbation de feuilles de temps (portée 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 alors contenir la portée create:timesheets. De la même façon, pour supprimer des feuilles de temps existantes, le jeton d’accès doit contenir la portée delete:timesheets.

Pour en savoir plus sur les portées, consultez Scopes.

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

Rôles OAuth

Dans tout flux OAuth 2.0, on peut identifier les rôles suivants :

• Resource Owner : l’entité qui peut accorder l’accès à une ressource protégée. Il s’agit généralement de l’utilisateur final.
• Resource Server : le serveur qui héberge les ressources protégées. C’est l’API à laquelle vous voulez accéder.
• Client : une application qui demande l’accès à une ressource protégée pour le compte du Resource Owner.
• serveur d’autorisation : le serveur qui authentifie le Resource Owner et émet des jetons d’accès après avoir obtenu l’autorisation nécessaire. Dans ce cas-ci, il s’agit de l’Authentication API d’Auth0.

Les types d’autorisation (ou flux) déterminent comment ces participants interagissent pour accorder aux applications un accès limité aux API que vous développez. Par conséquent, l’application obtiendra un jeton d’accès qu’elle pourra utiliser pour faire une requête à l’API au nom de l’utilisateur.

​

Octroi implicite

OAuth 2.0 offre plusieurs types d’octroi pour différents cas d’utilisation. Dans ce cas d’utilisation précis, nous voulons accéder à l’API à partir d’une application côté client.

La SPA utilisera le flux implicite (octroi implicite) pour ce faire.

L’octroi implicite (défini dans la RFC 6749, section 4.1) est semblable à l’octroi utilisé dans le flux de code d’autorisation, mais la principale différence est que l’application reçoit directement un jeton d’accès, sans avoir besoin d’un authorization_code. Cela s’explique par le fait que l’application, qui est généralement une application JavaScript exécutée dans un navigateur, est considérée comme moins fiable qu’une application web exécutée sur le serveur; on ne peut donc pas lui confier le client_secret (qui est requis dans l’octroi par code d’autorisation).

Une fois l’utilisateur authentifié, l’application reçoit le ID Token et le jeton d’accès dans le fragment de hachage de l’URI. L’application peut maintenant utiliser l’ID Token pour obtenir des renseignements sur l’utilisateur, et le jeton d’accès pour envoyer une requête à l’API au nom de l’utilisateur.

1. L’application démarre le flux et redirige le navigateur vers Auth0 (plus précisément vers le point de terminaison /authorize), afin que l’utilisateur puisse s’authentifier.
2. Auth0 authentifie l’utilisateur. La première fois que l’utilisateur passe par ce flux, si l’application est une application tierce, une page de consentement s’affiche; elle présente les permissions qui seront accordées au client (par exemple, publier des messages, afficher des contacts, etc.).
3. Auth0 redirige l’utilisateur vers l’application avec un jeton d’accès (et, facultativement, un ID Token) dans le fragment de hachage de l’URI. L’application peut maintenant extraire les jetons du fragment de hachage.
4. L’application peut utiliser le jeton d’accès pour envoyer une requête à l’API au nom de l’utilisateur.

​

Authorization Extension

L’Auth0 Authorization Extension vous permet de configurer des rôles, des groupes et des permissions, puis de les attribuer à des utilisateurs.

• Les permissions sont les actions qu’une personne peut effectuer. Pour répondre aux besoins d’affaires d’ExampleCo, nous configurerons quatre permissions : lire, créer, supprimer et approuver des feuilles de temps.
• Les rôles sont des ensembles de permissions. L’application de feuilles de temps d’ExampleCo sera utilisée par deux types d’utilisateurs (employés et gestionnaires), chacun ayant des permissions différentes; nous configurerons donc deux rôles : employé et gestionnaire.

Comme cela répond à notre cas d’utilisation, nous ne créerons aucun groupe.

L’Authorization Extension créera une Rule qui lira les rôles, les groupes et les permissions attribués à un utilisateur et ajoutera cette information au profil utilisateur pendant le flux d’authentification. Nous pouvons utiliser cette information pour nous assurer que le jeton d’accès émis à un utilisateur ne contient que les portées autorisées. Nous pourrons ensuite personnaliser notre application, par exemple en désactivant la fonctionnalité Approve Timesheets si l’utilisateur n’a pas la permission requise pour le faire.