OAuth 2.0

Qu'est-ce que OAuth 2.0?

OAuth 2.0 est une norme IETF qui décrit un protocole de sécurisation des API. L'un des points forts d'OAuth 2.0 est la possibilité pour un utilisateur final de déléguer certaines de ses autorisations sur un service à une application (potentiellement sans rapport).

📘

What about OAuth 1.0?

Il existe également un protocole OAuth 1.0a qui offre des capacités similaires. Il nécessite la génération de hachages cryptographiques qui, tout en augmentant la sécurité, rendent le protocole plus difficile à mettre en œuvre pour les développeurs. OAuth 1.0a est beaucoup moins répandu qu'OAuth 2.0 et n'est pas pris en charge par IBM Security Verify

Quel problème OAuth résout-il ?

Sans OAuth, un service API exigera souvent que les demandes incluent les informations d'identification de l'utilisateur final (par exemple, un nom d'utilisateur et un mot de passe) pour authentifier l'accès. Une application souhaitant accéder au service au nom d'un utilisateur doit lui demander ses informations d'identification, puis se faire passer pour lui. Il s'agit d'un mauvais modèle :

• l'utilisateur n'a aucun moyen de limiter ce que l'application fait avec ses données d'identification
• l'utilisateur n'a aucun moyen de révoquer l'accès à l'application (sans changer son mot de passe)

Comment fonctionne OAuth ?

Avec OAuth, un service API exige que les demandes incluent un jeton d'accès qui renvoie à (ou encapsule) des données d'autorisation telles qu'un utilisateur final associé, l'étendue de l'accès ou une limite de temps. Une application souhaitant accéder au service (en son nom propre ou au nom d'un utilisateur) doit d'abord obtenir un jeton d'accès auprès du serveur d'autorisation associé au service API.

Un jeton d'accès est obtenu à l'aide d'un flux spécifique au type de subvention. Il existe de nombreux types de subventions définis pour différents cas d'utilisation. Ces questions seront abordées dans d'autres documents de la présente section.

Dans le cadre de la demande de jeton d'accès, l'application peut spécifier l' étendue de l' accès qu'elle souhaite. Le serveur d'autorisation peut décider d'accorder ou non tout ou partie des champs d'application demandés (sur la base de la logique de son choix). Pour certains types de subventions, le serveur d'autorisation peut demander à l'utilisateur final de consentir aux champs d'application demandés par l'application. Cela permet à l'utilisateur final de contrôler (ou au moins de voir) quelle autorité est déléguée.

Un jeton d'accès a généralement une durée de vie limitée. Selon le type de jeton d'accès utilisé, il peut être possible pour l'utilisateur (ou le service) de révoquer le jeton d'accès avant même l'expiration de ce délai.

Format du jeton d'accès

Selon l'implémentation, un jeton d'accès OAuth peut être soit :

• une chaîne de caractères aléatoires qui indexe l' autorisation (informations sur l'accès accordé) dans un magasin de données détenu par le serveur d'autorisation ; ou
• un jeton signé (généralement un jeton Web JSON) qui encapsule les informations relatives à la subvention.

Index aléatoire

Lorsque le jeton d'accès est un index, un service recevant le jeton peut appeler un point de terminaison d'introspection sur le serveur d'autorisation pour demander les informations de subvention associées au jeton d'accès. Ces informations comprennent un état, indiquant si le jeton est actif ou inactif, et peuvent également inclure l'identité de l'utilisateur associé et les champs d'application accordés.

Étant donné que le jeton d'accès n'a aucune signification sans les données d'octroi associées stockées sur le serveur d'autorisation, il est possible de révoquer le jeton d'accès de manière centralisée en supprimant simplement cette association.

Jeton Web JSON (JWT)

Lorsque le jeton d'accès est un jeton Web JSON, un service recevant le jeton peut le valider et extraire les données qu'il contient sans avoir à rappeler le serveur d'autorisation. Cela permet de réduire les appels au réseau, mais au prix d'un contrôle central de la révocation. Un jeton d'accès sous la forme d'un jeton Web JSON est valable jusqu'à la date d'expiration spécifiée dans le jeton et ne peut être révoqué.

💎

Jon Harry, IBM Security