Le type d’autorisation implicite est utilisé lorsque l’application ne s’appuie pas sur un serveur (back end). Dans ce cas, il n’est pas possible d’obtenir les jetons en arrière-plan dans une liaison de serveur à serveur :
- application basées sur un navigateur (javscript),
- application autonome (ordinateur de bureau et appareils mobiles).

Les jeton sont obtenu directement par appel au contrôleur Authorize.

Authentification utilisant le flux de code implicite

  publie le par DnC

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é.

Le flux Implicite n’est pas aussi sécurisé que le flux de code d’autorisation pour deux raisons :
- Aucun appel au canal 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 oeuvre avec des clients publics connus, exploitant un URI de redirection particulier.

On emploiera généralement ce flux dans une application de navigateur utilisant un langage de script comme JavaScript.

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. Parce que le jeton d’accès est encodé 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 [1].

Lorsque la valeur de response_type est "token" [2], la demande est 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

PHP

  1. <?php
  2. /* implicit2.php
  3. Test élémentaire du serveur OIDC avec le flux "Implicit".
  4. see : https://bshaffer.github.io/oauth2-server-php-docs/grant-types/client-credentials/
  5.  
  6. Auteur : Bertrand Degoy
  7. Copyright (c) 2019 DnC
  8. licence GPL
  9. */
  10.  
  11. $client_id = 'oa_dnc_global';
  12. $client_secret = 'Bydf5x!LmXjo';
  13.  
  14. $server = 'oa.dnc.global';
  15. $authorization_endpoint = 'https://' . $server . '/authorize';
  16. $token_endpoint = 'https://' . $server . '/token';
  17. $introspection_endpoint = 'https://' . $server . '/introspect';
  18. $userinfo_endpoint = 'https://' . $server . '/userinfo';
  19.  
  20. define('PRIVATE', true);
  21. require_once __DIR__.'/../../oidc/includes/configure.php';
  22. require_once __DIR__.'/../../oidc/includes/server.php';
  23.  
  24.  
  25. $data = array(
  26. 'response_type' => 'id_token token',
  27. 'client_id' => $client_id,
  28. 'scope' => 'openid profile',
  29. 'state' => 'gsfgrfgqgqsf',
  30. 'nonce' => 'kfjghsfklgqsfkgqsdfu',
  31. );
  32.  
  33. $authorization_endpoint .= '?' . http_build_query($data);
  34. header('Location: ' . $authorization_endpoint);
  35. exit();

Télécharger

Références :
- OpenID Connect Implicit Client Implementer’s Guide,

Notes

[1Vérifier que cela répond à la spécification.

[2Le standard ne prévoit pas cela ?