Authentification utilisant le flux de code implicite

B. Degoy — 2018-11-15T21:42:00Z

Le type d'autorisation implicite effectue une demande d'accès pour le compte d'un utilisateur, comme le flux d'autorisation avec code.

Cependant, contrairement au flux de code d'autorisation dans lequel le client effectue une demande d'autorisation et une demande de jeton d'accès distinctes, le client reçoit le jeton d'accès comme résultat de la demande d'autorisation.

Le serveur d'autorisation renverra directement au client un jeton d'accès et / ou d'identité.

Ce flux est utilisé si l'application cliente fait appel aux données protégées à partir de l'agent utilisateur (user-agent). Elle est alors dite "sans back-end" [1]. Ce peut être une application Javascript fonctionnant dans le navigateur de l'utilisateur ou une application "native". Dans ce cas, le flux de code d'autorisation ne peut être utilisé [2].

Le flux Implicite n'est pas aussi sécurisé que le flux de code d'autorisation pour deux raisons :
– Aucun appel à l'application cliente (URL de retour) n'est effectué. De ce fait, le client ne peut être authentifié.
– le jeton est transmis par l'URL.
Ce flux n'est sécurisé que dans la mesure où il est mis en œuvre avec des clients publics connus, exploitant un URI de redirection particulier.

Comme il s'agit d'un flux basé sur la redirection, le client doit être capable d'interagir avec l'agent utilisateur du propriétaire de la ressource (généralement un navigateur) et capable de recevoir les demandes entrantes (via la redirection) depuis le serveur d'autorisation.

Le type d'autorisation n'inclut pas l'authentification du client, et s'appuie sur la présence du propriétaire de la ressource et l'enregistrement de l'URI de redirection [3]. Parce que le jeton d'accès est transmis dans l'adresse URI de redirection, il peut être exposé au propriétaire de la ressource et à d'autres applications résidant sur le même appareil.

Ce flux utilise le contrôleur d'autorisation, mais pas le contrôleur de jeton.

Lorsque la valeur de response_type est "id_token token", le jeton d'identité est toujours émis, que le scope "openid" soit inclus dans la requête ou non.

Lorsque la valeur de response_type est "token", il s'agit d'un flux implicite défini dans le document RFC 6749. Même si openid est inclus dans le paramètre scope, aucun jeton d'identité n'est émis.

Exemple de requête Implicit Grant

...

Références :
– OpenID Connect Implicit Client Implementer's Guide,

[1] Notons qu'une application Web s'appuie sur un serveur. Ce qui classifie "sans back-end" l'application est le fait que les données protégées sont accédées depuis le client Web ou depuis une application installée sur un ordinateur de bureau ou un mobile, et non depuis le serveur de l'application Web.

[2] Puisqu'il n'y a pas de liaison de serveur à serveur. Il existe cependant des configurations permettant d' utiliser le flux Authorization Code avec une application native, voir : Applications natives : un exemple avec Windev.

[3] à ne pas confondre avec l'URI de retour du flux de code d'autorisation.

OpenID Connect OAuth Server dédié

Authentification utilisant le flux de code implicite

Exemple de requête Implicit Grant