Créer la demande de prélèvement automatique

Modifier en ligne

Utilisez ces informations pour créer une requête JWT pré-autorisée qui sera utilisée dans le flux de code pré-autorisé.

Réclamations relatives à la charge utile des demandes préautorisées

La charge utile de la requête préautorisée doit contenir les revendications suivantes.

Tableau 1. Allégations de MUST
Nom de la réclamation Descriptif Valeurs valides
iss Identifiant unique de l'émetteur du certificat d'authentification ayant émis le JWT URI valide de l'émetteur des identifiants.
sub Identificateur du sujet principal Identificateur unique d'un utilisateur.
exp Délai d'expiration du JWT Nombre de secondes depuis le 1970-01-01T0:0:0Z, mesuré en temps universel coordonné.
Remarque : la durée de validité du JWT ne peut pas dépasser 3 600 secondes à compter du moment présent.
jti Identificateur JWT Chaîne opaque générée de manière aléatoire

La charge utile de la requête préautorisée peut contenir les revendications suivantes.

Tableau 2. Allégations de MAY
Nom de la réclamation Descriptif Valeurs valides
aud L'émetteur du serveur d'autorisation est publié sur un point de terminaison bien connu. URI valide de l'émetteur des identifiants.
sub_type Type d'identifiant principal du sujet. Soit « uid », « username » ou « 'externalId' ». La valeur par défaut est « uid ».
domaine Domaine du sujet principal Le domaine d'identité auquel appartient le sub .
iat Heure de création du JWT Nombre de secondes depuis le 1970-01-01T0:0:0Z, mesuré en temps universel coordonné.
Remarque : la date de création du JWT ne peut pas remonter à plus de 3 600 secondes dans le passé.
tx_code Remplacement des paramètres préautorisés par l'émetteur des identifiants. Un objet JSON contenant les revendications décrites dans le tableau des revendications du code de transaction.
État de l'émetteur Une valeur opaque permettant d'associer le contexte de l'émetteur des identifiants au jeton d'accès généré. Une chaîne quelconque. Il peut également s'agir d'un JWT.

Cette tx_code demande ne prendra effet que si cette dérogation est autorisée dans les paramètres de préautorisation. Dans ce mode, lorsqu'une tx_code demande d'indemnisation est déposée, un code de transaction est généré. Les tables de codes de transaction décrivent les options de remplacement possibles.

Tableau 3. Réclamations relatives aux codes de transaction
Nom de la réclamation Descriptif Valeur valide
mode_saisie Déterminez le jeu de caractères du code de transaction. Soit « numérique » (uniquement des chiffres), soit « texte » (alphanumérique)
longueur Déterminez la longueur du code de transaction. Une valeur numérique comprise entre 4 et 10
description Message que l'application de portefeuille doit afficher à l'utilisateur final. N'importe quelle chaîne
canal Expliquez comment communiquer le code de transaction à l'utilisateur final. Un objet JSON contenant les revendications décrites dans le tableau 4 ci-dessous.

Trois canaux sont disponibles pour transmettre le code de transaction : e-mail, SMS ou tout autre moyen déterminé par l'émetteur des identifiants. Dans ce dernier cas, le serveur d'autorisation se contente de renvoyer le code de transaction à l'émetteur des identifiants.

Tableau 4. Allégations relatives aux chaînes
Nom de la réclamation Descriptif Valeur valide
l'année en cours Type de canal utilisé pour transmettre le code de transaction à l'utilisateur final. Soit « e-mail », « SMS » ou « émetteur »
valeur Adresse e-mail de l'utilisateur final (pour type = e-mail) ou numéro de téléphone (pour type = sms). Une adresse e-mail ou un numéro de téléphone valide.

Exemple de charge utile d'une requête pré-autorisée

{
  "iss": "https://www.credential-issuer.com",
  "sub": "user@idsource.com",
  "sub_type": "username",
  "aud": "https://sometenant.ice.com/oauth2",
  "exp": 1324298520,
  "jti": "araiov8werli2awerlj",
  "tx_code": {
    "input_mode": "text",
    "length": 6,
    "description": "Please provide this transaction code:",
    "channel": {
       "type": "email",
       "value": "bob@ibm.com"
    },
  },
  "issuer_state": "sa82jpawfagnns"
}

Algorithmes pris en charge

La requête JWT pré-autorisée peut être signée à l'aide de l'un des algorithmes suivants : RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384 et PS512.

La validité de ce JWT est vérifiée à partir de l'URI JWKS de l'émetteur des identifiants. Assurez-vous que le JWT signé inclut l'en-tête kid permettant d'identifier de manière unique la clé utilisée, car l'URI JWKS peut publier plusieurs clés. La configuration de l'URI JWKS de l'émetteur de credentials s'effectue dans les paramètres de fédération. Vérifiez que l'identifiant de l'émetteur correspond à celui iss indiqué dans la charge utile de la requête.

Exemple de demande

Une fois le JWT de pré-autorisation créé, une requête peut être envoyée au point de terminaison de pré-autorisation afin de générer un code de pré-autorisation.
 curl -ki -X POST https://<tenantId>/oauth2/preauth --data "eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJpc3Mi..." -H "Content-Type:application/jwt"