Aperçu de la solution (SPAs + API)

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

Afin de s’assurer que seuls les utilisateurs et les applications autorisés peuvent accéder à l’API Timesheets, 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 octrois lui permettent d’autoriser facilement les divers types d’applications qui doivent communiquer avec l’API Timesheets.

​

Authentification et autorisation des 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’API et recevoir de l’information en réponse.

Un point de terminaison d’API peut être sécurisé ou non. Dans notre cas, puisque les feuilles de temps sont 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 sur une API, elle doit présenter un Jeton d’accès comme preuve qu’elle possède les autorisations requises pour appeler le point de terminaison.

Un Jeton d’accès est obtenu en authentifiant l’utilisateur auprès d’un serveur d’autorisation, puis 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 qui représente une autorisation accordée à l’application. Il peut s’agir d’un identifiant utilisé pour récupérer l’information d’autorisation, ou encore contenir lui-même cette information (par exemple, l’identité de l’utilisateur, les autorisations, etc.) d’une manière vérifiable.

Il est assez courant que les jetons d’accès soient implémentés 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 précis sur les personnes qui peuvent accéder aux différents points de terminaison qu’elle expose. Ces autorisations sont exprimées sous forme de scopes.

Lorsqu’un utilisateur autorise une application cliente, celle-ci peut aussi indiquer les autorisations dont elle a besoin. L’utilisateur peut alors examiner et accorder ces autorisations. Celles-ci sont ensuite incluses dans le Jeton d’accès dans la revendication scope.

Par la suite, lorsque l’application cliente transmet le Jeton d’accès dans ses requêtes à l’API, l’API peut inspecter la revendication scope pour s’assurer que les autorisations requises ont bien été accordées afin d’appeler le point de terminaison d’API en question.

Que sont les scopes ?

Chaque Jeton d’accès peut inclure une liste des autorisations qui ont été accordées à l’application. Lorsqu’une application s’authentifie auprès d’Auth0, elle précise la liste des scopes (ou autorisations) qu’elle demande. Si ces scopes sont autorisés, le Jeton d’accès contiendra alors une liste des scopes autorisés.

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

Lorsqu’une application demande à l’API de créer une nouvelle entrée de feuille de temps, le Jeton d’accès doit contenir le scope create:timesheets. De la même façon, pour supprimer des feuilles de temps existantes, le Jeton d’accès doit contenir le scope delete:timesheets.

Pour en savoir plus sur les scopes, consultez Scopes.

En utilisant le cadre d’autorisation OAuth 2.0, vous pouvez donner à vos propres applications ou à des applications tierces un accès limité à vos API pour le compte 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 des API.

Rôles OAuth

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

• Propriétaire de la ressource : l’entité qui peut accorder l’accès à une ressource protégée. Il s’agit généralement de l’utilisateur final.
• Serveur de ressources : le serveur qui héberge les ressources protégées. Il s’agit de l’API à laquelle vous voulez accéder.
• Application : une application qui demande l’accès à une ressource protégée au nom du propriétaire de la ressource.
• Serveur d’autorisation : le serveur qui authentifie le propriétaire de la ressource et émet des jetons d’accès après avoir obtenu l’autorisation requise. Dans ce cas-ci, il s’agit de l’Authentication API d’Auth0.

Les types d’octroi (ou flux) déterminent comment ces participants interagissent afin d’accorder aux applications un accès limité aux API que vous créez. L’application obtiendra ainsi un jeton d’accès qui pourra être utilisé pour appeler l’API au nom de l’utilisateur.

​

Octroi implicite

OAuth 2.0 fournit plusieurs types d’octroi pour différents cas d’utilisation. Dans ce cas 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 un Jeton d’accès directement, sans qu’un authorization_code soit nécessaire. Cela s’explique par le fait que l’application, 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 hash 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 appeler l’API au nom de l’utilisateur.

1. L’application lance le flux et redirige le navigateur vers Auth0 (plus précisément vers le /authorize endpoint), afin que l’utilisateur puisse s’authentifier.
2. Auth0 authentifie l’utilisateur. La première fois que l’utilisateur passe par ce flux, et si l’application est une application tierce, une page de consentement s’affichera, où les autorisations accordées à l’application seront listées (par exemple, publier des messages, afficher la liste des contacts, etc.).
3. Auth0 redirige l’utilisateur vers l’application avec un Jeton d’accès (et, au besoin, un ID Token) dans le fragment hash de l’URI. L’application peut maintenant extraire les jetons de ce fragment hash.
4. L’application peut utiliser le Jeton d’accès pour appeler l’API au nom de l’utilisateur.

​

Authorization Extension

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

• Les autorisations correspondent aux actions qu’une personne peut effectuer. Pour répondre aux besoins d’affaires d’ExampleCo, nous configurerons quatre autorisations : lire, créer, supprimer et approuver des feuilles de temps.
• Les rôles sont des ensembles d’autorisations. L’application de feuilles de temps d’ExampleCo sera utilisée par deux types d’utilisateurs (les employés et les gestionnaires), chacun ayant des autorisations 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 autorisations attribués à un utilisateur, puis 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 scopes autorisés. Nous pourrons ensuite personnaliser notre application, par exemple en désactivant la fonctionnalité d’approbation des feuilles de temps si l’utilisateur n’a pas l’autorisation requise pour le faire.