OpenID Connect OAuth Server dédié

Spécification de la demande "offline_access"

Traduction du document OpenID Connect Core 1.0 incorporating errata set 1 § 11 :

11. Accès hors ligne
OpenID Connect définit la valeur de portée suivante pour demander un accès hors ligne :

offline_access

OPTIONNEL. Cette valeur de portée demande qu’un jeton d’actualisation OAuth 2.0 soit émis et puisse être utilisé pour obtenir un jeton d’accès qui accorde un accès au point de terminaison UserInfo [1] de l’utilisateur final même lorsque l’utilisateur final n’est pas présent (non connecté).

Lorsqu’un accès hors connexion est demandé, une valeur de paramètre d’invite de consentement DOIT être utilisée [2], sauf si d’autres conditions de traitement de la demande permettant un accès hors connexion aux ressources demandées sont en place. L’OP DOIT toujours obtenir l’autorisation de renvoyer un jeton d’actualisation permettant un accès hors ligne aux ressources demandées. Un consentement de l’utilisateur préalablement enregistré ne suffit pas toujours pour accorder un accès hors connexion [3].

À la réception d’un paramètre d’étendue contenant la valeur offline_access, le serveur d’autorisations :

 DOIT s’assurer que le paramètre prompt contient un consentement sauf si d’autres conditions de traitement de la demande permettant un accès hors ligne aux ressources demandées sont en place ; sauf si l’une de ces conditions ou les deux sont remplies, il DOIT alors ignorer la demande offline_access,
 DOIT ignorer la demande offline_access sauf si le client utilise une valeur response_type qui entraînerait le renvoi d’un code d’autorisation,
 DOIT explicitement recevoir ou avoir le consentement de tous les clients lorsque le type d’application enregistré est Web,
 DEVRAIT recevoir explicitement ou avoir le consentement de tous les clients lorsque le type d’application enregistré est natif.

L’utilisation des jetons d’actualisation n’est pas exclusive au cas d’utilisation offline_access. Le serveur d’autorisations PEUT accorder des jetons d’actualisation dans d’autres contextes qui ne relèvent pas de la portée de cette spécification [4].

Cas d’usage

L’objectif est de permettre à une application d’effectuer des opérations au nom d’un utilisateur final alors que celui-ci est hors ligne (le jeton d’accès n’est plus valide).

Un exemple est une sauvegarde périodique de certaines données chaque nuit.

Lors de la connexion, l’application cliente demandera le consentement de l’utilisateur en appelant le contrôleur Authorize avec la valeur ’offline_access’ dans le paramètre scope.

L’application devra enregistrer le jeton de rafraîchissement obtenu de façon persistante pour l’utiliser ultérieurement, même si l’utilisateur est déconnecté.

OAuthSD accorde une acception générale au jeton d’actualisation et en assure un contrôle serré

Certaines implémentations distinguent le jeton d’actualisation obtenu avec le consentement de l’utilisateur en réponse à la demande "offline_access" du jeton d’actualisation "ordinaire" (fourni sans ce consentement). Il est alors nommé "jeton hors ligne".

Nous ne voyons rien de tel dans les spécifications ni dans les tests de certification. Nous nous en tiendrons à l’interprétation de Brent Shaffer matérialisée dans la librairie OAuth 2.0 Server PHP :

Les demandes OpenID Connect incluent le jeton d’actualisation (refresh token) uniquement si la portée offline_access a été demandée et accordée.

Autrement dit : dans le cadre d’OpenID Connect, le jeton d’actualisation a une portée générale. Qu’il soit utilisé pour un scénario "hors ligne" ou pour tout autre usage ne dépend que du concepteur de l’application [5].

Bonnes pratiques pour la sécurité

Nous sommes d’avis que permettre l’actualisation du jeton d’accès affaiblit la sécurité des flux OpenID Connect (comme toute forme de délivrance de jeton en dehors du flux d’autorisation avec code).
Si vous mettez en œuvre le jeton d’actualisation, voyez les recommandations de cet article : Rafraîchir (actualiser) un jeton d’accès.