Types d'octroi

Modifier en ligne

Un type d'autorisation indique le mécanisme d'autorisation utilisé par le client pour récupérer le jeton d'identification et le jeton d'accès auprès de Verify. Vous pouvez choisir parmi les options suivantes : code d'autorisation, autorisation implicite, code d'autorisation et autorisation implicite, flux d'appareil, identifiants du propriétaire de la ressource, JWT, autorisation basée sur le contexte, jeton d'actualisation et échange de jetons.

Consultez les tableaux ci-dessous pour une comparaison des types d'octroi pris en charge et pour déterminer le type d'octroi à définir pour l'application.
Tableau 1. Types de subventions
Caractéristiques Code préautorisé Code d'autorisation Implicite Code d'autorisation et Implicite
Descriptif /preauth Le point de terminaison de pré-autorisation renvoie un code de pré-autorisation. Le code préautorisé est échangé contre un jeton d'accès. /tokenL'authentification du client est requise pour obtenir un jeton d'accès auprès du point de terminaison des jetons.

Le noeud final d'autorisation /authorize renvoie un code d'autorisation. Celui-ci peut être échangé contre un jeton d'ID, un jeton d'accès ou un jeton d'actualisation.

L'authentification du client est requise avec un ID et un secret client pour l'extraction du jeton d'ID ou du jeton d'accès depuis le noeud final de jeton /token.

Il s'agit du flux le plus couramment utilisé.

Le noeud final d'autorisation /authorize renvoie directement un jeton d'ID ou un jeton d'accès.

Il n'utilise pas de code d'autorisation ni de noeud final de jeton /token.

Il permet à l'avant-plan et à l'arrière-plan du client de recevoir les jetons indépendamment les uns des autres.

Le client obtient un code d'autorisation et des jetons depuis le noeud final d'autorisation /authorize. Certains jetons sont demandés au noeud final de jeton /token.
Cas d'utilisation Utilisé dans le cadre de la délivrance de certificats lorsque :
  • L'authentification et l'autorisation des utilisateurs sont assurées par l'émetteur des identifiants.
  • Les identifiants délivrés ne nécessitent pas un niveau de sécurité élevé, par exemple pour acheter un billet de cinéma.

Utilisez cette option pour les clients qui peuvent conserver un secret client de manière sécurisée, comme les applications Web et les applications mobiles natives.

Il sert à authentifier l'utilisateur et le client.

Utilisez cette option pour les clients qui ne peuvent pas conserver un secret client, comme les applications de navigateur ou JavaScript.

Elle permet d'authentifier l'utilisateur.
Utilisez cette option pour les clients qui :
  • Peuvent conserver un secret client de manière sécurisée, comme les applications Web et les applications mobiles natives.
  • Requièrent l'accès au jeton d'ID pour obtenir les informations d'identité.
  • Requièrent des jetons dont la durée de vie est plus longue grâce à des jetons d'actualisation.
Valeur de type de réponse Non applicable 
code
 
id_token
token
id_token token
 
code id_token
code token
code id_token token
Tous les jetons sont renvoyés depuis le noeud final d'autorisation. Non applicable Non Oui Non
Tous les jetons sont renvoyés depuis le noeud final de jeton. Oui Oui Non Non
Les jetons ne sont pas exposés à l'agent utilisateur. Oui Oui Non Non
L'application client peut être authentifiée. Oui Oui Non Oui
Génération de jetons d'actualisation. Oui Oui Non Oui
Communication en un aller-retour Non Non Oui Non
Communication interserveur majoritairement Oui Oui Non Variable
Suggestion de connexion (login_hint) Non Oui
Il peut s'agir du nom d'utilisateur sous forme de chaîne, par exemple john@ibm.com, ou sous forme de code JSON, par exemple
{"realm":"securityVerifyRealm",
"username":"john@ibm.com"}
. Lorsque vous utilisez une valeur JSON, le domaine représente le domaine source d'identité.
 Oui
Il peut s'agir du nom d'utilisateur sous forme de chaîne, par exemple john@ibm.com, ou sous forme de code JSON, par exemple
{"realm":"securityVerifyRealm",
"username":"john@ibm.com"}
. Lorsque vous utilisez une valeur JSON, le domaine représente le domaine source d'identité.
 Oui
Il peut s'agir du nom d'utilisateur sous forme de chaîne, par exemple john@ibm.com, ou sous forme de code JSON, par exemple
{"realm":"securityVerifyRealm",
"username":"john@ibm.com"}
. Lorsque vous utilisez une valeur JSON, le domaine représente le domaine source d'identité.
Ancienneté maximale de l'authentification (max_age) Non applicable Cette valeur correspond au temps écoulé admis, en secondes, depuis la dernière authentification de l'utilisateur. Cet attribut s'applique uniquement aux sessions de connexion Cloud Directory. Cette valeur correspond au temps écoulé admis, en secondes, depuis la dernière authentification de l'utilisateur. Cet attribut s'applique uniquement aux sessions de connexion Cloud Directory. Cette valeur correspond au temps écoulé admis, en secondes, depuis la dernière authentification de l'utilisateur. Cet attribut s'applique uniquement aux sessions de connexion Cloud Directory.
Flux de travaux
  1. L'émetteur des identifiants authentifie l'utilisateur final et obtient son autorisation.
  2. L'émetteur du certificat demande le code de pré-autorisation au serveur d'autorisation Verify.
  3. Le serveur d'autorisation Verify génère le code de pré-autorisation.
  4. Le serveur d'autorisation Verify peut, s'il le souhaite, envoyer le code de transaction à l'utilisateur final.
  5. L'émetteur du certificat transmet le code préautorisé au portefeuille.
  6. Le portefeuille demande à l'utilisateur final de saisir le code de transaction (le cas échéant).
  7. Le portefeuille remplace le code préautorisé par un jeton d'accès.
  8. Wallet utilise le jeton d'accès pour récupérer les identifiants auprès de l'émetteur d'identifiants.
  1. Le client prépare une demande d'authentification contenant les paramètres de demande requis.
  2. Le client envoie la requête au Verify serveur d'autorisation.
  3. Le Verify serveur d'autorisation authentifie l'utilisateur.
  4. Le Verify serveur d'autorisation obtient le consentement ou l'autorisation de l'utilisateur.
  5. Le Verify serveur d'autorisation renvoie l'utilisateur vers le client avec un code d'autorisation.
  6. Le client demande une réponse d'authentification en utilisant le code d'autorisation sur le noeud final de jeton.
  7. Le client reçoit une réponse dont le corps contient un jeton d'ID et un jeton d'accès.
  8. Le client valide le jeton d'ID et extrait l'identificateur du sujet de l'utilisateur.
  1. Le client prépare une demande d'authentification contenant les paramètres de demande requis.
  2. Le client envoie la requête au Verify serveur d'autorisation.
  3. Le Verify serveur d'autorisation authentifie l'utilisateur.
  4. Le Verify serveur d'autorisation obtient le consentement ou l'autorisation de l'utilisateur.
  5. Le Verify serveur d'autorisation renvoie l'utilisateur vers le client avec un jeton d'identification et, si nécessaire, un jeton d'accès.
  6. Le client valide le jeton d'ID et extrait l'identificateur du sujet de l'utilisateur.
  1. Le client prépare une demande d'authentification contenant les paramètres de demande requis.
  2. Le client envoie la requête au Verify serveur d'autorisation.
  3. Le Verify serveur d'autorisation authentifie l'utilisateur.
  4. Le Verify serveur d'autorisation obtient le consentement ou l'autorisation de l'utilisateur.
  5. Le Verify serveur d'autorisation renvoie l'utilisateur vers le client avec un code d'autorisation et, selon le type de réponse, un ou plusieurs paramètres.
  6. Le client demande une réponse en utilisant le code d'autorisation comme noeud final de jeton.
  7. Le client reçoit une réponse dont le corps contient un jeton d'ID et un jeton d'accès.
  8. Le client valide le jeton d'ID et extrait l'identificateur du sujet de l'utilisateur.
Tableau 2. Types de subventions (suite)
Caractéristiques Flux de dispositifs Données d'identification du mot de passe du propriétaire de la ressource JWT
Descriptif Il permet au client d'être habilité avec un code Quick Response ou un code utilisateur qui est envoyé à une URL. Le client et l'utilisateur doivent s'authentifier avec un ID client, un secret client, un nom d'utilisateur et un mot de passe pour pouvoir extraire le jeton d'accès et le jeton d'ID depuis le noeud final de jeton/jeton. Le nom d'utilisateur et le mot de passe sont validés à l'aide de Cloud Directory. Défini dans RFC7523. Permet à un client de présenter un JWT signé ou chiffré, ou signé et chiffré, en échange d'un octroi. Le JWT est validé par le serveur d'autorisation et l'identité au sein du JWT est utilisée comme sujet de l'octroi.
Cas d'utilisation
Utilisez cette option pour les clients qui :
  • Ne disposent pas d'un navigateur pour exécuter un flux OAuth reposant sur un agent utilisateur.
  • Pour lesquels la saisie est restreinte dans la mesure où il est peu pratique de demander à l'utilisateur d'entrer une grande quantité de texte.
Exemple : sur les télévisions intelligentes, sur les consoles médias, dans les cadres numériques et sur les imprimantes.
 Ce type d'octroi peut être activé, mais ne l'utilisez que si aucun autre flux n'est disponible. Il peut être utilisé pour :
  • Les propriétaires de ressource qui ont une relation d'accréditation avec le client, par exemple le système d'exploitation de l'appareil ou une application associée à des privilèges élevés.
  • Les clients qui peuvent obtenir les données d'identification du propriétaire de la ressource (nom d'utilisateur et mot de passe) via un formulaire interactif.
  • La migration de clients existants qui utilisent des schémas d'authentification directe tels que l'authentification de base HTTP ou l'authentification simplifiée auprès de OAuth en convertissant les données d'identification stockées en jeton d'accès.
 Il existe une relation de confiance établie entre le serveur d'autorisation (Verify) et une entité qui émet des jetons JWT. Le client obtient un JWT auprès de l'entité émettrice du JWT et le présente au serveur d'autorisation en échange d'un octroi. L'entité émettrice du JWT peut avoir ses propres exigences, qui doivent être satisfaites avant l'émission d'un JWT (par exemple, l'authentification alternative et les contrôles d'autorisation).
Valeur de type de réponse Non applicable Non applicable Non applicable
Tous les jetons sont renvoyés depuis le noeud final d'autorisation. Non Non Non
Tous les jetons sont renvoyés depuis le noeud final de jeton. Oui Oui Oui
Les jetons ne sont pas exposés à l'agent utilisateur. Oui Oui Oui
L'application client peut être authentifiée. Oui Oui Oui
Génération de jetons d'actualisation. Oui Oui Oui
Communication en un aller-retour
Communication interserveur majoritairement
Suggestion de connexion (login_hint) Non Non Non
Ancienneté maximale de l'authentification (max_age) Non applicable
Flux de travaux
  1. L'utilisateur démarre le flux en envoyant l'ID client depuis l'appareil pour demander un code utilisateur ou un code d'appareil.
  2. Si l'ID client est valide, l'URI de vérification, un code utilisateur et un code d'appareil sont renvoyés.
  3. L'appareil affiche l'URI de vérification et le code utilisateur que l'utilisateur peut entrer dans un navigateur ou affiche un code Quick Response que l'utilisateur peut scanner.
  4. L'appareil tente constamment d'échanger le code d'appareil contre un jeton.
  5. L'utilisateur scanne ou entre l'URI de vérification et le code utilisateur manuellement pour envoyer le code utilisateur au service OIDC.
  6. Si le code utilisateur est valide, un message de réussite est envoyé et le code d'appareil est échangé contre un jeton d'accès.
  1. L'utilisateur entre son nom d'utilisateur et son mot de passe dans un formulaire du côté de la partie utilisatrice.
  2. Le client envoie le nom d'utilisateur, le mot de passe, l'ID client et le secret client au noeud final de jeton.
  3. Le nom d'utilisateur et le mot de passe sont validés à l'aide de Cloud Directory.
  4. Le client reçoit une réponse dont le corps contient un jeton d'ID et un jeton d'accès.
  1. Le client obtient un JWT (par tous les moyens externes) et le présente au noeud final.
  2. Le JWT est validé et le sujet et les attributs supplémentaires sont extraits.
  3. Le client reçoit une réponse dont le corps contient un jeton d'ID et un jeton d'accès.
Tableau 3. Types de subventions (suite)
Caractéristiques Autorisation contextuelle Actualiser le jeton Echange de jetons
Descriptif Flux géré par API dans lequel des vérifications d'authentification et d'autorisation supplémentaires sont effectuées. Avant qu'un octroi ne soit émis pour le client, une authentification multi-facteur peut être requise. L'authentification du client et de l'utilisateur est requise à l'aide d'un identifiant client, d'un secret client et d'un jeton de rafraîchissement afin d'obtenir un nouvel ensemble de jetons d'accès, de jetons d'identification et de jetons de rafraîchissement auprès du point de terminaison des jetons /token. Le jeton d'actualisation doit correspondre au même identifiant de client. Les valeurs des attributs associés au jeton ne sont pas actualisées au cours de ce flux. Définie dans RFC8693. Permet à un client de présenter un jeton en vue de l'échanger contre un autre jeton.
Cas d'utilisation

  • Le client doit être instrumenté pour traiter une réponse au type de demande d'authentification à partir du serveur d'autorisation.

  • Le client utilise les API de facteurs d'authentification disponibles dans Verify [...], afin de recevoir un JWT, qui est ensuite présenté pour poursuivre le processus.
  • Le client doit inclure des informations contextuelles supplémentaires dans la requête via le paramètre "context".
 Utilisez ce type d'autorisation pour obtenir un nouvel ensemble de jetons d'accès, avec une durée de validité renouvelée. Cela permet de limiter la durée de validité du jeton d'accès sans pour autant obliger l'utilisateur à se reconnecter pour en obtenir un nouveau.

  • Usurpation d'identité : le fait pour un client d'accéder à une ressource en se faisant passer pour une autre entité.

  • Délégation : le fait pour un mandataire d'agir au nom d'une entité habilitée.
Valeur de type de réponse Non applicable Non applicable Non applicable
Tous les jetons sont renvoyés depuis le noeud final d'autorisation. Non Non Non
Tous les jetons sont renvoyés depuis le noeud final de jeton. Oui Oui Oui
Les jetons ne sont pas exposés à l'agent utilisateur. Oui Oui Oui
L'application client peut être authentifiée. Oui Oui Oui
Génération de jetons d'actualisation. Oui Oui Oui
Communication en un aller-retour Oui
Communication interserveur majoritairement Oui
Suggestion de connexion (login_hint) Non Non Non
Ancienneté maximale de l'authentification (max_age) Non applicable Non
Flux de travaux
  1. Le client lance le processus en fournissant un certain « contexte » via une requête utilisant grant_type=Context-based authorization
  2. Le client reçoit un message DENY (si l'accès ne doit pas être autorisé dans ce contexte) ou CHALLENGE (identifié via la portée qui est renvoyée).
  3. Le client utilise le jeton d'accès qui est renvoyé avec la réponse à la demande d'authentification pour accéder aux API des facteurs d'authentification disponibles, y compris l'indicateur permettant de demander un JWT comme résultat de l'exécution d'un facteur.
  4. Le JWT renvoyé par le facteur exécuté est présenté à /token sous forme de demande d'octroi de jeton bearer JWT (le contexte doit également être inclus) et des jetons sont émis.
Remarque :
  • En fonction de la stratégie configurée, une fois le premier facteur exécuté, des facteurs supplémentaires peuvent être requis. Ces facteurs peuvent nécessiter l'exécution d'un deuxième CHALLENGE et d'un deuxième facteur d'authentification.
  • Ce type d'octroi requiert qu'une stratégie d'accès personnalisée soit créée et jointe à l'application. Cette stratégie d'accès doit contenir des règles pour l'authentification du premier facteur et, le cas échéant, des exigences 2FA.
  1. Le client constate que le jeton d'accès arrive à expiration ou a expiré, et souhaite obtenir de nouveaux jetons d'accès.
  2. Le client envoie ses identifiants et son jeton d'actualisation au point de terminaison des jetons.
  3. Le jeton d'actualisation et les informations d'identification du client sont validés.
  4. Le client reçoit une réponse dont le corps contient un jeton d'identification, un jeton d'actualisation et un jeton d'accès.

  1. Le client génère ou récupère un jeton qui servira de jeton de sujet. Il pourra également comporter un jeton d'acteur.

  2. Envoyez une requête au point de terminaison des jetons du serveur d'autorisation en indiquant le jeton du sujet et, si vous le souhaitez, le jeton de l'acteur.

  3. Le serveur d'autorisation renvoie le jeton demandé.