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,