La suite de cet article est une traduction d’un extrait de OpenID Connect Core 1.0 avec nos commentaires.
3.1. Authentification utilisant le flux de code d’autorisation OpenID Connect (Authorization Code Flow).
Cette section explique comment effectuer l’authentification à l’aide du Flux du code d’autorisation [1].
Lorsque vous utilisez le Flux du code d’autorisation, tous les jetons sont renvoyés du point d’extrémité du jeton [2].
Le Flux du code d’autorisation renvoie un code d’autorisation au client [3], qui peut alors l’échanger directement pour un jeton d’identification et un jeton d’accès. Cela offre l’avantage de ne pas exposer de jetons à l’agent utilisateur et éventuellement à d’autres applications malveillantes avec accès à l’agent utilisateur. Le serveur d’autorisation peut également authentifier le client avant d’échanger le code d’autorisation d’un jeton d’accès. Le flux du code d’autorisation est adapté aux applications clientes qui peuvent maintenir en toute sécurité un secret entre eux et le serveur d’autorisation.
3.1.1. Étapes du flux d’autorisation
Le Flux du code d’autorisation passe par les étapes suivantes :
Le client prépare une demande d’authentification contenant les paramètres de demande souhaités.
3.1.2. Point d’extrémité Autorization
Le point d’extrémité d’autorisation effectue l’authentification de l’utilisateur final. Pour ce faire, l’agent utilisateur doit être envoyé au point d’extrémité d’autorisation pour authentification et autorisation du serveur d’autorisations à l’aide des paramètres de requête définis par OAuth 2.0 et de paramètres et valeurs supplémentaires définis par OpenID Connect.
La communication avec le noeud final d’autorisation DOIT utiliser TLS. Voir Section 16.17 pour plus d’informations sur l’utilisation de TLS.
3.1.2.1. Paramètres d’autorisation
Les serveurs d’autorisation DOIVENT prendre en charge l’utilisation des méthodes HTTP GET et POST définies dans le RFC 2616 [RFC2616] au niveau du point d’extrémité d’autorisation. Les clients PEUVENT utiliser les méthodes HTTP GET ou POST pour envoyer la demande d’autorisation au serveur d’autorisation. Si vous utilisez la méthode HTTP GET, les paramètres de requête sont sérialisés à l’aide de la sérialisation de chaîne de requête URI, conformément à la Section 13.1. Si vous utilisez la méthode HTTP POST, les paramètres de demande sont sérialisés à l’aide de la sérialisation de formulaire, conformément à la Section 13.2.
OpenID Connect utilise les paramètres de requête OAuth 2.0 suivants avec le flux de codes d’autorisation :
CHAMPS OBLIGATOIRES. Les demandes OpenID Connect DOIVENT contenir la valeur de la portée d’autorisation openid. Si la valeur openid n’est pas présente, le comportement est entièrement non spécifié. D’autres valeurs de domaine PEUVENT être présentes. Les valeurs de portée utilisées qui ne sont pas comprises par une implémentation DEVRAIENT être ignorées. Voir les sections 5.4 et 11 pour les valeurs de portée supplémentaires définies par cette spécification.
CHAMPS OBLIGATOIRES. OAuth 2.0 Response Type Valeur qui détermine le flux de traitement des autorisations à utiliser, y compris les paramètres renvoyés par les ordinateurs d’extrémité utilisés. Lorsque vous utilisez le flux de codes d’autorisation, cette valeur est "code".
CHAMPS OBLIGATOIRES. Identificateur de client OAuth 2.0 valide sur le serveur d’autorisations.
CHAMPS OBLIGATOIRES. URI de redirection auquel la réponse sera envoyée. Cet URI DOIT correspondre exactement à l’une des valeurs d’URI de redirection pour le client préenregistré auprès du fournisseur OpenID, la correspondance étant effectuée comme décrit dans le paragraphe 6.2.1 de la [RFC3986] (comparaison de chaînes simples). Lors de l’utilisation de ce flux, l’URI de redirection DEVRAIT utiliser le schéma https; Cependant, il PEUT utiliser le schéma http, à condition que le type de client soit confidentiel, tel que défini dans la section 2.1 de OAuth 2.0, et que l’OP autorise l’utilisation des URI de redirection http dans ce cas. L’URI de redirection PEUT utiliser un autre schéma, tel qu’un schéma destiné à identifier un rappel dans une application native.
CONSEILLÉ [5]. Valeur opaque utilisée pour conserver l’état entre la demande et le rappel. En règle générale, l’atténuation de la falsification de requêtes intersites (CSRF, XSRF) s’effectue en liant de manière cryptographique la valeur de ce paramètre à un cookie de navigateur.OpenID Connect utilise également le paramètre de requête OAuth 2.0 suivant, défini dans la section Pratiques de codage de types de réponses multiples de OAuth 2.0 [OAuth.Responses] :
OPTIONNEL. Informe le serveur d’autorisations du mécanisme à utiliser pour renvoyer des paramètres à partir du point d’extrémité d’autorisation. Cette utilisation de ce paramètre n’est PAS RECOMMANDÉE lorsque le mode de réponse qui serait demandé est le mode par défaut spécifié pour le type de réponse.Cette spécification définit également les paramètres de requête suivants :
OPTIONNEL. Valeur de chaîne utilisée pour associer une session client à un jeton d’ID et pour limiter les attaques de relecture. La valeur est transmise non modifiée de la demande d’authentification au jeton d’ID. Une entropie suffisante DOIT être présente dans les valeurs nonce utilisées pour empêcher les attaquants de deviner des valeurs. Pour les notes sur la mise en œuvre, voir la section 15.5.2.
OPTIONNEL. Valeur de chaîne ASCII indiquant comment le serveur d’autorisations affiche les pages d’interface utilisateur d’authentification et de consentement à l’utilisateur final. Les valeurs définies sont :
- page
Le serveur d’autorisation DEVRAIT afficher l’interface utilisateur d’authentification et de consentement cohérente avec une vue complète de la page de l’agent d’utilisateur. Si le paramètre d’affichage n’est pas spécifié, il s’agit du mode d’affichage par défaut.
- popup
Le serveur d’autorisation DEVRAIT afficher l’interface utilisateur d’authentification et de consentement cohérente avec une fenêtre d’agent d’utilisateur contextuelle. La fenêtre de l’agent d’utilisateur contextuelle doit être d’une taille appropriée pour une boîte de dialogue axée sur la connexion et ne doit pas masquer toute la fenêtre sur laquelle elle apparaît.
- touch
Le serveur d’autorisation DEVRAIT afficher une interface utilisateur d’authentification et de consentement cohérente avec un dispositif utilisant une interface tactile.
- wap
Le serveur d’autorisations DEVRAIT afficher l’interface utilisateur d’authentification et de consentement cohérente avec un affichage de type "smartphone".
Le serveur d’autorisations PEUT aussi tenter de détecter les capacités de l’agent d’utilisateur et présenter un affichage approprié.
OPTIONNEL. Liste de valeurs [6] de chaînes ASCII, séparées par des espaces et respectant la casse, spécifiant si le serveur d’autorisations invite l’utilisateur final à demander une nouvelle authentification et son consentement. Les valeurs définies sont :
- none
Le serveur d’autorisations NE DOIT PAS afficher de pages d’interface utilisateur d’authentification ou de consentement. Une erreur est renvoyée si un utilisateur final n’est pas déjà authentifié ou si le client ne dispose pas du consentement préconfiguré pour les revendications demandées ou ne remplit pas les autres conditions de traitement de la demande. Le code d’erreur sera généralement login_required, interaction_required ou un autre code défini dans la section 3.1.2.6. Ceci peut être utilisé comme méthode pour vérifier l’authentification et / ou le consentement existants. [7]
- login
Le serveur d’autorisation DEVRAIT demander à l’utilisateur final une nouvelle authentification. S’il ne peut pas réauthentifier l’utilisateur final, il DOIT retourner une erreur, généralement login_required.
- consent
Le serveur d’autorisation DEVRAIT demander à l’utilisateur final son consentement avant de retourner les informations au client. S’il ne peut pas obtenir le consentement, il DOIT retourner une erreur, généralement consent_required.
- select_account
Le serveur d’autorisation DEVRAIT demander à l’utilisateur final de sélectionner un compte d’utilisateur. Cela permet à un utilisateur final disposant de plusieurs comptes sur le serveur d’autorisations de choisir parmi plusieurs comptes pour lesquels il peut avoir des sessions en cours. S’il ne peut pas obtenir de choix de compte effectué par l’utilisateur final, il DOIT retourner une erreur, généralement account_selection_required.
OPTIONNEL. Âge d’authentification maximum. Spécifie le temps écoulé autorisé en secondes depuis la dernière fois que l’utilisateur final a été authentifié activement par l’OP. Si le temps écoulé est supérieur à cette valeur, l’OP DOIT tenter de ré-authentifier activement l’utilisateur final. (Le paramètre max_age request correspond au paramètre de requête OpenID 2.0 PAPE [OpenID.PAPE] max_auth_age.) Lorsque max_age est utilisé, le jeton ID renvoyé DOIT inclure une valeur de déclaration auth_time.
OPTIONNEL. Langues et scripts préférés de l’utilisateur final pour l’interface utilisateur, représentés par une liste de valeurs d’étiquette de langue BCP47 [RFC5646] séparées par des espaces, triées par préférence. Par exemple, la valeur "fr-CA fr en" représente une préférence pour le français parlé au Canada, puis le français (sans désignation de région), suivi de l’anglais (sans désignation de région). Une erreur NE DEVRAIT PAS se produire si certains ou tous les paramètres régionaux demandés ne sont pas pris en charge par le fournisseur OpenID.
OPTIONNEL. Le jeton ID précédemment émis par le serveur d’autorisations est transmis en tant qu’indicateur sur la session authentifiée actuelle ou passée de l’utilisateur final avec le client. Si l’utilisateur final identifié par le jeton ID est connecté ou est connecté par la requête, le serveur d’autorisations renvoie une réponse positive. sinon, il DEVRAIT retourner une erreur, telle que login_required. Si possible, un id_token_hint DEVRAIT être présent lorsque prompt = none est utilisé et une erreur invalid_request PEUT être renvoyée si ce n’est pas le cas ; Cependant, le serveur DEVRAIT répondre avec succès lorsque cela est possible, même s’il n’est pas présent. Authorization Server n’a pas besoin d’être répertorié en tant qu’audience du jeton ID lorsqu’il est utilisé en tant que valeur id_token_hint.
Si le jeton d’identification reçu par le RP en provenance de l’OP est chiffré, pour l’utiliser comme id_token_hint, le client DOIT déchiffrer le jeton d’identification signé contenu dans le jeton d’identification chiffré. Le client PEUT rechiffrer le jeton d’identification signé sur le serveur d’authentification à l’aide d’une clé permettant au serveur de déchiffrer le jeton d’ID et utiliser le jeton d’ID rechiffré en tant que valeur id_token_hint.
OPTIONNEL. Indication au serveur d’autorisations sur l’identifiant de connexion que l’utilisateur final peut utiliser pour se connecter (si nécessaire). Cet indice peut être utilisé par un RP s’il demande d’abord à l’adresse électronique (ou à un autre identifiant) de messagerie électronique, puis de transmettre cette valeur au conseil en tant qu’indicateur. Il est RECOMMANDÉ que la valeur de conseil corresponde à la valeur utilisée pour la découverte. Cette valeur PEUT aussi être un numéro de téléphone dans le format spécifié pour la revendication n ° de téléphone. L’utilisation de ce paramètre est laissée à la discrétion du PO.
OPTIONNEL. Valeur de "Requested Authentication Context Class Reference". Chaîne séparée par des espaces spécifiant les valeurs acr que le serveur d’autorisations est invité à utiliser pour traiter cette demande d’authentification, les valeurs apparaissant par ordre de préférence. La classe de contexte d’authentification satisfaite par l’authentification effectuée est renvoyée sous la valeur de revendication acr, comme spécifié à la section 2. La revendication acr est demandée en tant que revendication volontaire par ce paramètre.D’autres paramètres PEUVENT être envoyés. Voir les sections 3.2.2, 3.3.2, 5.2, 5.5, 6 et 7.2.1 pour connaître les paramètres de demande d’autorisation et les valeurs de paramètre supplémentaires définis par cette spécification.
RSS 2.0