Aperçu de solution (Applications mobiles + API)

Aperçu des solutions pour le scénario d’architecture du Mobile + 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.

Le Flux de code d’autorisation présente certains problèmes de sécurité lorsqu’il est implémenté sur des applications natives. Par exemple, un attaquant malveillant peut intercepter le authorization_code fourni par Auth0 et l’échanger pour un jeton d’accès (et possiblement un jeton d’actualisation).

La Proof Key for Code Exchange (PKCE) (défini dans RFC 7636) est une technique utilisée pour mitiger cette attaque d’interception de code d’autorisation.

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 native 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 .
2. Auth0 redirige l’utilisateur vers l’application native avec un authorization_code dans le lien de demande.
3. L’application native envoie le authorization_code et le code_verifier ensemble avec le redirect_uri et le client_id vers Auth0. Cela se fait en utilisant le point de terminaison /oauth/token.
4. Auth0 valide cette information et retourne un jeton d’accès (et éventuellement un jeton d’actualisation).
5. L’application native peut utiliser le jeton d’accès pour appeler l’API pour 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

L’Authorization Extension d’Auth0 vous permet de fournir une prise en charge des autorisations dans votre application, en assignant des rôles, des groupes et des autorisations aux utilisateurs.

L’Authorization Extension crée une Rule (Règle) qui augmentera le profil utilisateur durant le flux d’authentification avec les rôles, les groupes et les autorisations assignés à l’utilisateur. Vous pouvez ensuite utiliser ces informations pour garantir que le jeton d’accès émis à un utilisateur contient uniquement les permissions autorisées en fonction des autorisations définies dans l’Authorization Extension.

TUTORIEL PRÉCÉDENT Introduction

TUTORIEL SUIVANT 2. Configuration Auth0