OAuth 2.0, qui signifie « Open Authorization » (autorisation ouverte), est une norme conçue pour permettre à un site Web ou à une application d'accéder aux ressources hébergées par d'autres applications Web au nom d'un utilisateur. Elle a remplacé OAuth 1.0 en 2012 et constitue désormais la norme industrielle de facto pour l'autorisation en ligne. OAuth 2.0 fournit un accès consenti et limite les actions que l'application cliente peut réaliser sur les ressources au nom de l'utilisateur, sans jamais partager les informations d'identification de l'utilisateur.

Bien que le Web soit la principale plateforme d'OAuth 2, la spécification décrit également comment gérer ce type d'accès délégué à d'autres types de clients (applications basées sur un navigateur, applications Web côté serveur, applications natives/mobiles, appareils connectés, etc.)

OAuth 2.0 est un protocole d'autorisation et NON un protocole d'authentification. En tant que tel, il est principalement conçu comme un moyen d'accorder l'accès à un ensemble de ressources, par exemple, des API distantes ou des données utilisateur.

OAuth 2.0 utilise des jetons d'accès. Un jeton d'accès est un élément de données qui représente l'autorisation d'accéder aux ressources au nom de l'utilisateur final. OAuth 2.0 ne définit pas de format spécifique pour les jetons d'accès. Toutefois, dans certains contextes, le format JSON Web Token (JWT) est souvent utilisé. Cela permet aux émetteurs de jetons d'inclure des données dans le jeton lui-même. En outre, pour des motifs de sécurité, les jetons d'accès peuvent avoir une date d'expiration.

Le concept de rôles fait partie de la spécification de base du cadre d'autorisation OAuth2.0. Ils définissent les composants essentiels d'un système OAuth 2.0, qui sont les suivants :

• Propriétaire des ressources : l'utilisateur ou le système qui possède les ressources protégées et peut en accorder l'accès.

• Client : le client est le système qui a besoin d'accéder aux ressources protégées. Pour accéder aux ressources, le client doit détenir le jeton d'accès approprié.

• Serveur d'autorisation : ce serveur reçoit les demandes de jetons d'accès de la part du client et les délivre après authentification et consentement du propriétaire des ressources. Le serveur d'autorisation expose deux points de terminaison : le point de terminaison d'autorisation, qui gère l'authentification et le consentement interactifs de l'utilisateur, et le point de terminaison de jeton, qui fait partie d’une interaction de machine à machine.

• Serveur de ressources : un serveur qui protège les ressources de l'utilisateur et reçoit les demandes d'accès du client. Il accepte et valide un jeton d'accès du client et lui renvoie les ressources appropriées.

Les champs d'application sont un concept important d'OAuth 2.0. Ils permettent de spécifier exactement le motif pour lequel l'accès aux ressources peut être accordé. Des valeurs de champ d'application acceptables, et les ressources auxquelles elles se rapportent, dépendent du serveur de ressources.

Le serveur d'autorisation OAuth 2 ne peut pas renvoyer directement un jeton d'accès après que le propriétaire de la ressource ait autorisé l'accès. À la place, et pour une meilleure sécurité, il est possible de renvoyer un Code d'autorisation qui est ensuite échangé contre un jeton d'accès. En outre, le serveur d'autorisation peut également émettre un jeton d'actualisation avec le jeton d'accès. Contrairement aux jetons d'accès, les jetons d'actualisation ont normalement une longue durée d'expiration et peuvent être échangés contre de nouveaux jetons d'accès lorsque ces derniers expirent. En raison de ces propriétés, les jetons d’actualisation doivent être stockés de manière sécurisée par les clients.

Au niveau le plus élémentaire, avant de pouvoir utiliser OAuth 2.0, le client doit acquérir ses propres informations d'identification, un identifiant client et un code secret de client, auprès du serveur d'autorisation afin de s'identifier et de s'authentifier lorsqu'il demande un jeton d'accès.

Avec OAuth 2.0, les demandes d'accès sont initiées par le client, par exemple une application mobile, un site Web, une application de télévision intelligente, une application de bureau, etc. La demande de jeton, l'échange et la réponse suivent ce flux général :

1. Le client demande une autorisation (demande d'autorisation) au serveur d'autorisation, en fournissant l'identifiant et le secret du client comme identification. Il spécifie les champs d'application et une URI de point de terminaison (URI de redirection) pour envoyer le jeton d'accès ou le code d'autorisation.

2. Le serveur d'autorisation authentifie le client et vérifie que les champs d'application demandés sont autorisés.

3. Le propriétaire de la ressource interagit avec le serveur d'autorisation pour accorder l'accès.

4. Le serveur d'autorisation redirige vers le client avec un code d'autorisation ou un jeton d'accès, selon le type d'attribution, comme cela sera expliqué dans la section suivante. Un jeton d'actualisation peut également être renvoyé.

5. Avec le jeton d'accès, le client demande l'accès à la ressource au serveur de ressources.

Dans OAuth 2.0, les attributions sont l'ensemble des étapes qu'un client doit effectuer pour obtenir une autorisation d'accès à une ressource. Le cadre d'autorisation fournit plusieurs types d'attribution pour répondre à différents scénarios :

• attribution de code d'autorisation : Le serveur d'autorisation renvoie au client un code d'autorisation à usage unique, qui est ensuite échangé contre un jeton d'accès. C'est la meilleure option pour les applications Web traditionnelles où l'échange peut se faire en toute sécurité du côté serveur. Le flux du code d'autorisation peut être utilisé par les applications monopages et les applications mobiles/natives. Cependant, dans ce cas, le code secret du client ne peut pas être stocké de manière sécurisée, et l'authentification, pendant l'échange, est donc limitée à l'utilisation de l’_identifiant du client_seul. Une meilleure alternative est le Code d'autorisation avec attribution PKCE, ci-dessous.

• Implicite Attribution : Un flux simplifié où le jeton d'accès est renvoyé directement au client. Dans le flux implicite, le serveur d'autorisation peut renvoyer le jeton d'accès comme paramètre dans l'URI de rappel, ou comme réponse à une publication de formulaire. La première option est désormais obsolète en raison du risque de fuite de jeton.

• Attribution d'un code d'autorisation avec une clé de preuve pour l'échange de code (PKCE) : Ce flux d'autorisation est similaire à l'attribution du code d'autorisation, mais avec des étapes supplémentaires qui le rendent plus sûr pour les applications mobiles/natives et les applications monopages.

• Type d'attribution des informations d'identification du propriétaire des ressources : Cette attribution exige que le client obtienne d'abord les informations d'identification du propriétaire de la ressource, qui sont transmises au serveur d'autorisation. Elle est donc limitée aux clients qui bénéficient d'une confiance totale. Elle présente l'avantage de ne pas impliquer de redirection vers le serveur d'autorisation, ce qui la rend applicable dans les cas d'utilisation où une redirection n'est pas possible.

• Type d'attribution des informations d'identification du client : Utilisée pour les applications non interactives, par exemple, les processus automatisés, les microservices, etc. Dans ce cas, l'application est authentifiée en tant que telle à l'aide de son identifiant client et de son code secret.

• Flux d'autorisation d'appareil : Une attribution qui permet l'utilisation d'applications sur des appareils dont la saisie est limitée, comme les téléviseurs intelligents.

• Attribution de jeton d'actualisation : Le flux implique l'échange d'un jeton d'actualisation contre un nouveau jeton d'accès.

Poursuivez la lecture de notre page Introduction à l'IAM pour explorer d'autres sujets relatifs à la gestion des identités et des accès.