Utiliser l'API d'authentification à plusieurs facteurs à la demande pour développer une page de connexion personnalisée

Ce cas d'utilisation fournit un exemple étape par étape d'utilisation de l'API REST des domaines d'identité pour authentifier les utilisateurs et effectuer l'inscription et l'authentification à plusieurs facteurs.

Remarque

Utilisez cette API d'authentification uniquement si vous créez votre propre expérience de connexion de bout en bout en développant une application de connexion personnalisée à utiliser par les domaines d'identité.

Remarque

Cette API d'authentification ne peut pas être utilisée pour intégrer vos applications à des domaines d'identité à des fins d'accès avec connexion unique.

L'API d'authentification à plusieurs facteurs On Demand est basée sur le concept de machine à états. Les réponses aux demandes informent un client d'application de ce qui doit être fait ensuite plutôt que d'exiger des utilisateurs que les cookies tiers soient activés dans leur navigateur. Les cookies tiers activés dans les navigateurs peuvent poser des problèmes, en particulier pour les applications B2C où les contrôles sur le comportement de l'utilisateur final ne peuvent pas être appliqués. L'élément requestState fourni dans chaque réponse de demande est utilisé dans la demande suivante, fournissant au client les informations dont il a besoin pour traiter la demande, puis fournissant l'ensemble d'opérations suivant autorisé.

L'API d'authentification à plusieurs facteurs On Demand peut :

Prendre en charge l'inscription des utilisateurs avec les facteurs d'authentification à plusieurs facteurs activés par l'administrateur
Renforcer la sécurité de l'authentification par mot de passe à l'aide de l'authentification à plusieurs facteurs (MFA) en exigeant une vérification supplémentaire, comme l'utilisation d'un code secret à usage unique basé sur le temps ou d'un code secret SMS.
Effectuer l'inscription à l'authentification à plusieurs facteurs, la vérification de l'authentification à plusieurs facteurs et la gestion du facteur d'authentification utilisateur.

Les exemples d'ensemble suivants sont inclus dans ce cas d'emploi :

Inscription de facteur avec vérification

Ces cas d'emploi fournissent des exemples de demande à l'aide de l'API REST des domaines d'identité qui permet à un utilisateur de s'inscrire à des facteurs d'authentification à plusieurs facteurs.

Les cas d'emploi suivants vous guident tout au long des étapes d'inscription de différents facteurs d'authentification à plusieurs facteurs à l'aide de l'API REST :

Extraire les facteurs inscrits d'un utilisateur

Ce cas d'utilisation fournit un exemple étape par étape d'utilisation de l'API de vérification des domaines d'identité pour extraire les facteurs auxquels un utilisateur est inscrit.

Ces étapes supposent que les facteurs pertinents de l'authentification à plusieurs facteurs sont activés à l'aide de Configurer les paramètres d'authentification à plusieurs facteurs.

Téléchargez la collection d'exemples de cas d'utilisation d'authentification des domaines d'identité et le fichier de variables globales à partir du dossier idcs-factor-enrollment-api dans le référentiel idm-samples GitHub, puis importez-les dans Postman.

L'étape à suivre dans ce cas d'emploi dépend de la demande à effectuer à l'aide de userGUID ou de User Name :

Remarque

Les exemples de cette section utilisent userGUID dans les demandes. Vous pouvez demander userGUID et userOcid dans vos demandes.

Etape 1 : Obtention des facteurs inscrits pour un utilisateur par userGUID

Cette étape obtient les facteurs inscrits pour un utilisateur en fonction de userGUID ou du nom utilisateur.

Exemple de demande

GET {{HOST}}/mfa/v1/users/{{userGUID}}/factors

Exemple de réponse

L'exemple suivant illustre le contenu de la réponse au format JSON :


{
    "userGUID": "7b3d902ab05b4214bae6b2924ca6be21",
    "status": "success",
    "preferredFactorId": "b3e04149d958437b9b801fa70c33ca70",
    "preferredMethod": "EMAIL",
    "factors": [
        {
            "factorId": "SecurityQuestions",
            "methods": [
                "SECURITY_QUESTIONS"
            ]
        },
        {
            "displayName": "+155XXXXX555",
            "factorId": "83889faeacaf4592a964405f87506fc6",
            "methods": [
                "SMS"
            ]
        },
        {
            "displayName": "uxxr1@example.com",
            "factorId": "b3e04149d958437b9b801fa70c33ca70",
            "methods": [
                "EMAIL"
            ]
        },
        {
            "factorId": "BypassCode",
            "methods": [
                "BYPASSCODE"
            ]
        }
    ]
}

La réponse contient les détails userGUID, le facteur préféré et le facteur inscrit.

Etape 2 : Obtenir les facteurs inscrits pour un utilisateur à l'aide de filtres

Vous pouvez obtenir les facteurs inscrits pour un utilisateur à l'aide du nom utilisateur ou du GUID utilisateur. Les valeurs userIdType suivantes sont acceptées :

USER_GUID : par exemple, userId doit contenir USER_GUID, tel que "7b3d902ab05b4214".
USER_NAME : par exemple, userId doit contenir USER_NAME, tel que John.

Exemple de demande pour extraire les facteurs inscrits en fonction du nom utilisateur

L'exemple suivant présente l'exemple de demande permettant d'obtenir les facteurs inscrits pour un utilisateur en fonction de son nom utilisateur au format JSON :


GET {{HOST}}/mfa/v1/users?userId=user1@example.com&userIdType=USER_NAME&attributes=factors

Exemple de réponse

L'exemple suivant illustre le contenu de la réponse au format JSON :

{
    "userGUID": "589879c55b7340518141eab82493f0cc",
    "status": "success",
    "preferredFactorId": "88178d80636a428393a5674ba46dc867",
    "preferredMethod": "SMS",
    "factors": [
        {
            "factorId": "BypassCode",
            "methods": [
                "BYPASSCODE"
            ]
        },
        {
            "displayName": "user1@example.com",
            "factorId": "30db2274140043918edb033d9fe29ff3",
            "methods": [
                "EMAIL"
            ]
        },
        {
            "displayName": "+1554455555",
            "factorId": "88178d80636a428393a5674ba46dc867",
            "methods": [
                "SMS"
            ]
        }
    ]
}

La réponse contient les détails userGUID, le facteur préféré et le facteur inscrit.

Exemple de demande d'extraction des facteurs inscrits en fonction du GUID utilisateur

L'exemple suivant montre l'exemple de demande permettant d'obtenir les facteurs inscrits pour un utilisateur en fonction de son GUID utilisateur au format JSON :


GET {{HOST}}/mfa/v1/users?userId=589879c55b7340518141eab82493f0cc&userIdType=USER_GUID&attributes=factors

Exemple de réponse

L'exemple suivant illustre le contenu de la réponse au format JSON :

{
    "userGUID": "589879c55b7340518141eab82493f0cc",
    "status": "success",
    "preferredFactorId": "88178d80636a428393a5674ba46dc867",
    "preferredMethod": "SMS",
    "factors": [
        {
            "factorId": "BypassCode",
            "methods": [
                "BYPASSCODE"
            ]
        },
        {
            "displayName": "user1@example.com",
            "factorId": "30db2274140043918edb033d9fe29ff3",
            "methods": [
                "EMAIL"
            ]
        },
        {
            "displayName": "+1554455555",
            "factorId": "88178d80636a428393a5674ba46dc867",
            "methods": [
                "SMS"
            ]
        }
    ]
}

La réponse contient les détails userGUID, le facteur préféré et le facteur inscrit.

Lancer et vérifier le facteur préféré

Ce cas d'utilisation fournit un exemple étape par étape d'utilisation de l'API Factor Enrollment des domaines d'identité pour s'inscrire à l'authentification multifacteur (MFA) avec vérification de facteur.

Ces étapes supposent que les facteurs pertinents de l'authentification à plusieurs facteurs sont activés à l'aide de Configurer les paramètres d'authentification à plusieurs facteurs.

Téléchargez la collection d'exemples de cas d'utilisation d'authentification des domaines d'identité et le fichier de variables globales à partir du dossier idcs-factor-verification-api dans le référentiel idm-samples GitHub, puis importez-les dans Postman.

Téléchargez la collection et le fichier de variables globales à partir du dossier idcs-factor-verification-api dans GitHub, puis importez-les dans Postman.

Utilisez les étapes suivantes pour le cas d'emploi. Chaque étape contient des exemples de demande et de réponse :

Remarque

Les exemples de cette section utilisent userGUID dans les demandes. Vous pouvez demander userGUID et userOcid dans vos demandes.

Step1 : lancer la vérification du facteur préféré

Cette étape lance la vérification du facteur préféré d'un utilisateur. Si vous devez utiliser l'API de facteur de vérification sans fournir userGUID, vous pouvez fournir un ID unique d'utilisateur tel que le nom utilisateur userId. La valeur userIdType dans la demande indique le type d'informations d'identification que l'utilisateur transmet en tant que valeur pour userId. Les valeurs userIdType suivantes sont acceptées :

USER_GUID : par exemple, userId doit contenir USER_GUID, tel que "7b3d902ab05b4214"
USER_NAME : par exemple, userId doit contenir USER_NAME, tel que John.

L'attribut userId contient la valeur réelle des informations d'identification utilisateur transmises.

Exemple de demande

L'exemple suivant montre la demande POST à l'adresse {{HOST}}/mfa/v1/requests au format JSON.

{
   "userId":"{{userGUID}}",
   "userIdType": "USER_GUID"
}

Exemple de réponse

L'exemple suivant présente le contenu de la réponse POST à l'adresse {{HOST}}/mfa/v1/requests au format JSON après le lancement du facteur préféré sur l'ID préféré :


{     
"status": "success",
"requestId": "f843736e-cbd8-4548-b41f-343b624a79fc",
"userGUID": "589879c55b7340518141eab82493f0cc",  
"factorId": "88178d80636a428393a5674ba46dc867",   
"method": "SMS",   
"displayName": "+4455665455",   
"requestState": "GwHJr3RvycjNEv.....MhQTLmWYzA/LVp0s"
}

Dans la réponse, la valeur requestId est l'identificateur unique généré pour cette demande. Incluez requestId dans chaque appel suivant pour terminer la vérification de facteur. factorId est le périphérique préféré sur lequel il a été lancé. method est le facteur que l'utilisateur a lancé. requestState contient les données contextuelles nécessaires au traitement de la demande.

Dans cet exemple, un otpCode (dans le cas d'un facteur SMS et EMAIL) est envoyé à l'aide de SMS vers l'appareil mobile de l'utilisateur.

Etape 2 : Vérifier le facteur préféré

Cette étape vérifie le facteur en transmettant otpCode dans une demande PATCH à {{HOST}}/mfa/v1/requests/{{requestId}}.

Le client doit inclure les attributs suivants :

otpCode: le code reçu par l'utilisateur sur son appareil
requestState : reçu dans la réponse de l'étape 1
requestId : reçu dans la réponse de l'étape 1

Exemple de demande

L'exemple suivant illustre le contenu de la demande PATCH au format JSON :

{  
"otpCode":"170230", 
"requestState": "{{requestState}}" 
}

Exemple de réponse

L'exemple suivant illustre le contenu de la réponse au format JSON :

{"status":"success"}

La réussite indique que la vérification a réussi.

Lancer et vérifier un facteur de sauvegarde

Ce cas d'utilisation fournit un exemple étape par étape d'utilisation de l'API de vérification des domaines d'identité pour effectuer la vérification du facteur de sauvegarde.

Ces étapes supposent que les facteurs pertinents de l'authentification à plusieurs facteurs sont activés à l'aide de Configurer les paramètres d'authentification à plusieurs facteurs.

Téléchargez la collection d'exemples de cas d'utilisation d'authentification des domaines d'identité et le fichier de variables globales à partir du dossier idcs-factor-verification-api dans le référentiel idm-samples GitHub, puis importez-les dans Postman.

Utilisez les étapes suivantes pour le cas d'emploi. Chaque étape contient des exemples de demande et de réponse :

Remarque

Les exemples de cette section utilisent userGUID dans les demandes. Vous pouvez demander userGUID et userOcid dans vos demandes.

Etape 1 : Lancer et vérifier les questions de sécurité du facteur de sauvegarde

Cette étape lance la vérification du facteur de sauvegarde d'un utilisateur. Le client doit fournir à la fois factorId et method dans la demande. Si vous devez utiliser l'API de facteur de vérification sans fournir userGUID, vous pouvez fournir un ID unique d'utilisateur tel que le nom utilisateur userId. La valeur userIdType dans la demande indique le type d'informations d'identification que l'utilisateur transmet en tant que valeur pour userId. Les valeurs userIdType suivantes sont acceptées :

USER_GUID : par exemple, userId doit contenir USER_GUID, tel que "7b3d902ab05b4214".
USER_NAME : par exemple, userId doit contenir USER_NAME, tel que Joe John.

L'attribut userId contient la valeur réelle des informations d'identification utilisateur transmises.

Pour obtenir la liste des facteurs inscrits et de leurs ID pour un utilisateur, reportez-vous au cas d'utilisation Extraire les facteurs inscrits d'un utilisateur. Dans cet exemple, le facteur de sauvegarde choisi est Questions de sécurité.

Exemple de demande de lancement de questions de sécurité de facteur de sauvegarde

L'exemple suivant présente le contenu de la demande POST vers l'adresse {{HOST}}/mfa/v1/requests/ au format JSON :

Remarque

La préférence factorId contient l'ID unique du facteur préféré. Dans le cas de SECURITY_QUESTIONS, il aura la chaîne fixe "SecurityQuestions".

{
    "userId":"{{userID}}",
    "userIdType":"USER_GUID",
    "factorId":"{{factorID}}",
    "method":"SECURITY_QUESTIONS"
}

Dans la réponse, la valeur requestId est l'identificateur unique généré pour cette demande. Incluez requestId dans chaque appel suivant pour terminer la vérification de facteur. Le fichier requestState contient les données contextuelles nécessaires au traitement de la demande.

Exemple de réponse

L'exemple suivant présente le contenu de la réponse au format JSON pour la méthode de sauvegarde SEQURITY_QUESTIONS :

{
    "status": "success",
    "requestId": "8da79411-5388-41ee-990e-935e74cb40f3",
    "userGUID": "589879c55b7340518141eab82493f0cc",
    "factorId": "SecurityQuestions",
    "method": "SECURITY_QUESTIONS",
    "requestState": "hBJIvkyfsXBv....movYarft8HlYANV3c+0",
    "securityQuestions": [
        {
            "id": "MaidenName",
            "localizedText": "What's your mother's maiden name?"
        }
    ]
}

Dans la réponse, la valeur requestId est l'identificateur unique généré pour cette demande. Incluez requestId dans chaque appel suivant pour terminer la vérification de facteur. Le fichier requestState contient les données contextuelles nécessaires au traitement de la demande. Dans cet exemple, une question est renvoyée de la liste des questions inscrites auxquelles l'utilisateur doit répondre.

Exemple de demande de vérification des questions de sécurité du facteur de sauvegarde

Cette étape vérifie le facteur de sauvegarde en transmettant la réponse à la question de sécurité dans une demande PATCH à {{HOST}}/mfa/v1/requests/{{requestID}}. Le client doit inclure les attributs suivants :

requestState: reçu dans la réponse de l'étape 1
securityQuestions id/answers : défini par l'utilisateur lors de l'inscription

Exemple de demande

L'exemple suivant illustre le contenu de la demande PATCH au format JSON pour SECURITY_QUESTIONS :

{
 "securityQuestions":[
        {
            "id":"MaidenName",
            "answer":"Smith"
        }
    ],
"requestState": "{{requestState}}"
 }

Exemple de réponse

L'exemple suivant illustre le contenu de la réponse au format JSON :

{"status":"success"}

La réussite indique que la vérification a réussi.

Etape 2 : Lancer et vérifier le facteur de sauvegarde EMAIL

Cette étape lance la vérification d'un facteur de sauvegarde EMAIL.

Exemple de demande de lancement du facteur EMAIL

L'exemple suivant illustre l'exemple de demande au format JSON pour la méthode préférée "EMAIL" :

{
    "userId":"{{userID}}",
    "userIdType":"USER_GUID",
    "factorId":"{{factorID}}",
    "method":"EMAIL"
}

Exemple de réponse

L'exemple suivant illustre l'exemple de réponse pour lancer le facteur EMAIL au format JSON :

{ 
 "status":"success",
 "requestId":"<Request ID>",
 "userGUID":"<User GUID>",
 "factorId":"factorID",
 "method":"EMAIL",
 "displayName":"Joe John",
 "requestState":"QYV81R9eoagwWQ"
 }

Exemple de demande de vérification du facteur EMAIL

L'exemple suivant illustre la demande PATCH au format JSON pour le facteur EMAIL :

{
    "otpCode":"170230"
     "requestState": "QYV81R9eoagwWQ"
 }

Exemple de réponse

L'exemple suivant montre le contenu de la réponse au format JSON pour vérifier le facteur EMAIL :

{"status":"success"}

La réussite indique que la vérification a réussi.

Renvoyer les facteurs de mot de passe à usage unique sans notifier l'utilisateur

Ce cas d'utilisation fournit un exemple de lancement de l'API d'authentification à plusieurs facteurs On Demand pour renvoyer des facteurs de code secret à usage unique (SMS, e-mail ou appel téléphonique) dans une réponse sans en informer l'utilisateur.

Téléchargez la collection d'exemples de cas d'utilisation d'authentification des domaines d'identité et le fichier de variables globales à partir du dossier idcs-factor-verification-api dans le référentiel idm-samples GitHub, puis importez-les dans Postman.

Ces étapes supposent que les facteurs pertinents de l'authentification à plusieurs facteurs sont activés à l'aide de Configuration des paramètres d'authentification à plusieurs facteurs.

Charge utile de la demande


Attribut	Valeurs prises en charge / exemples de valeur	Valeurs multiples	Détails d'utilisation
`userFlowControlledByExternalClient`	True / False	False	Définir cette option sur `true` et le mot de passe à usage unique sera renvoyé dans la réponse dans le format crypté spécifié. Remarque : le certificat utilisé pour le cryptage est téléchargé vers l'application à l'avance et est référencé à l'aide de l'attribut `x5t` dans l'exemple de demande tel que mentionné ci-dessous.
x5t	Chaîne / X509 Empreinte numérique du certificat SHA-1		Lorsque cette option est indiquée, le service utilise ce certificat téléchargé pour crypter les données de mot de passe à usage unique. Remarque : l'attribut "x5t" doit correspondre au certificat chargé.

Exemple de demande

{
    "userId":"<Unique Id>",
    "userIdType":"USER_NAME/USER_GUID",
    "userFlowControlledByExternalClient": true,
    "x5t" :"<certificate thumbprint>"
}

Charge utile de réponse


Attribut	Valeurs prises en charge / exemples de valeur	Valeurs multiples	Détails d'utilisation
`otp`	Correspondance `"otp": { "value": "IMCw==", "alg": "RSAES-OAEP", "x5t": "<certificate thumbprint>" }`	False	Lorsqu'il est présent dans la réponse, l'attribut contient le mot de passe à usage unique crypté avec les détails suivants. value : valeur cryptée. alg : algorithme utilisé pour le cryptage. x5t : empreinte numérique SHA-1 X509 du certificat utilisé pour le cryptage.

Exemple de réponse

{
    "status": "success",
    "requestId": "<Request ID>",
    "userGUID": "<User GUID>",
    "factorId": "<SMS/EMAIL/PHONE_CALL factor GUID>",
    "method": "SMS/EMAIL/PHONE_CALL",
    "displayName": "+91XXXXXXXX984",
    "requestState": "4p7ViEzP2bP1MIM",
    "otp": {
        "value": "<Encrypted OTP value>",
        "alg": "<Encryption algorithm>",
        "x5t": "<x5t of the certificate used to encrypt the OTP>"
           }
}

Inscription de facteur d'authentification avec vérification de facteur - SMS

Ces étapes supposent que les facteurs pertinents de l'authentification à plusieurs facteurs sont activés à l'aide de Configurer les paramètres d'authentification à plusieurs facteurs.

Utilisez les étapes suivantes pour le cas d'emploi. Chaque étape contient des exemples de demande et de réponse :

Remarque

Les exemples de cette section utilisent userGUID dans les demandes. Vous pouvez demander userGUID et userOcid dans vos demandes.

Etape 1 : Lancer l'inscription au facteur SMS

Cette étape lance l'inscription à SMS. Le client doit inclure les attributs suivants :

method : définit l'inscription au facteur SMS
phoneNumber : définit le numéro de téléphone où le texte SMS sera envoyé
countryCode : définit le code pays du numéro de téléphone où le texte SMS sera envoyé

Exemple de demande

L'exemple suivant montre la demande POST à l'adresse {{HOST}}/mfa/v1/users/{{userGUID}}/factors au format JSON :

{ 
"method": "SMS",
"countryCode": "+44", 
"mobileNumber": "1122334455", 
}

Exemple de réponse

L'exemple suivant illustre le contenu de la réponse au format JSON :

{
"status": "success", 
"factorId": "88178d80636a428393a5674ba46dc867",
"factorStatus": "ENROLLMENT_INITIATED", 
"methods": [ "SMS" ],
"displayName": "+1122334455", 
"requestState": "QK1.....y+OFP//0" 
}

displayName est le numéro de portable. Un otpCode sera envoyé à l'appareil mobile des utilisateurs, qui est utilisé pour terminer l'inscription.

Etape 1a : Renvoyer le mot de passe à usage unique

Si l'utilisateur ne reçoit pas le mot de passe à usage unique, cet exemple montre comment demander le renvoi d'un mot de passe à usage unique. Le client doit inclure les attributs suivants :

requestState: reçu dans la réponse de l'étape 1

resendOtp: Valeur booléenne indiquant que le mot de passe à usage unique est reçu

Exemple de demande

L'exemple suivant présente la demande PATCH à l'adresse {{HOST}}/mfa/v1/users/{{userGUID}}/factors/{{factorID}} au format JSON :

{
 "resendOtp":true,
 "requestState": "QK1.....y+OFP//0"
}

Exemple de réponse

L'exemple suivant illustre le contenu de la réponse au format JSON :

{ 
"status": "success",
"factorId": "88178d80636a428393a5674ba46dc867", 
"factorStatus": "ENROLLMENT_INITIATED",
"methods": [ "SMS" ],
"displayName": "+445544455",
"requestState": "+HFVV...qgMUI" 
}

La réponse contient les paramètres suivants :

requestState: qui doit être transmis par le client à l'étape suivante
displayName: est le numéro de téléphone portable en cours d'inscription.
method: Méthode de facteur SMS
Identifiant unique factorId: généré pour le facteur en cours d'inscription

Le succès indique que :

La valeur userGUID fournie est valide
L'utilisateur est actif
Le compte utilisateur n'est pas verrouillé
Le facteur SMS est activé

Etape 2 : Activer le facteur SMS

Cette étape active l'inscription SMS de l'utilisateur dans une demande PATCH à l'adresse /mfa/v1/users/{{userGUID}}/factors/{{factorID}}.

Le client doit inclure les attributs suivants :

otpCode: le code reçu par l'utilisateur sur son appareil
requestState : reçu dans la réponse de l'étape 1

Exemple de demande

L'exemple suivant illustre le contenu de la demande PATCH au format JSON :

{  
"otpCode":"170230", 
"requestState": "{{requestState}}"
 }

Exemple de réponse

L'exemple suivant illustre le contenu de la réponse au format JSON :

{"status":"success"}

Le succès indique que :

OTP est valide
La valeur userGUID fournie est valide
L'utilisateur est actif
Le compte utilisateur n'est pas verrouillé
Le facteur SMS est activé et le facteur est inscrit avec succès

Exemples de réponse d'erreur

L'exemple suivant montre le message d'erreur au format JSON lorsque userGUID n'est pas valide. Vous obtenez un code de réponse HTTP 404 si userGUID n'est pas valide.

{
    "status": "failed",
    "ecId": "0d1QwglU0000Fy",
    "cause": [
        {
            "code": "AUTH-3018",
            "message": "User not found."
        }
    ]
}

L'exemple suivant montre le message d'erreur au format JSON lorsque l'utilisateur est verrouillé. Vous obtenez un code de réponse HTTP 401.

{
    "status": "failed",
    "ecId": "0ISDCif1Qy6wg0000A8",
    "cause": [
        {
            "code": "AUTH-1010",
            "message": "Your account is locked.Contact your system administrator."
        }
    ]
}

Inscription de facteur d'authentification avec vérification de facteur - Courriel

Ces étapes supposent que les facteurs pertinents de l'authentification à plusieurs facteurs sont activés à l'aide de Configurer les paramètres d'authentification à plusieurs facteurs.

Utilisez les étapes suivantes pour le cas d'emploi. Chaque étape contient des exemples de demande et de réponse :

Remarque

Les exemples de cette section utilisent userGUID dans les demandes. Vous pouvez demander userGUID et userOcid dans vos demandes.

Etape 1 : Lancer l'inscription au facteur e-mail

Cette étape lance l'inscription par e-mail. Le client doit inclure l'attribut suivant :

method : définit l'inscription par courriel. L'utilisateur ne transmettra pas l'ID courriel. L'ID courriel principal est automatiquement extrait du profil de l'utilisateur.

Exemple de demande

L'exemple suivant présente le contenu de la demande POST vers l'adresse {{HOST}}/mfa/v1/users/{{userGUID}}/factors au format JSON :

{ 
"method": "EMAIL",
}

Exemple de réponse

L'exemple suivant illustre le contenu de la réponse au format JSON :

{
    "status": "success",
    "factorId": "30db2274140043918edb033d9fe29ff3",
    "factorStatus": "ENROLLMENT_INITIATED",
    "methods": [
        "EMAIL"
    ],
    "displayName": "user1@example.com",
    "requestState": "Vxar...bWTTA"
}

Un otpCode sera envoyé à l'ID courriel de l'utilisateur, qui est utilisé pour terminer l'inscription.

La réponse contient :

requestState: qui doit être transmis par le client à l'étape suivante
Adresse électronique displayName: de l'utilisateur inscrit
method: Méthode du facteur EMAIL

Le succès indique que :

L'inscription du facteur a été lancée.

Etape 1a : Renvoyer le mot de passe à usage unique

L'exemple suivant montre la demande PATCH à l'adresse {{HOST}}/mfa/v1/users/{{userGUID}}/factors/{{factorID}} au format JSON.

Si l'utilisateur ne reçoit pas le mot de passe à usage unique, cet exemple montre comment demander le renvoi d'un mot de passe à usage unique. Le client doit inclure les attributs suivants :

requestState: reçu dans la réponse de l'étape 1
resendOtp: pour indiquer que le mot de passe à usage unique est reçu

Exemple de demande

L'exemple suivant illustre le contenu de la demande PATCH au format JSON :

{  
"resendOtp":true, 
 "requestState": "QK1.....y+OFP//0"
 }

L'exemple suivant illustre le contenu de la réponse au format JSON :

{    
"status": "success",     
"factorId": "30db2274140043918edb033d9fe29ff3",
"factorStatus": "ENROLLMENT_INITIATED",   
"methods": ["EMAIL"],
"displayName": "username@example.com", 
"requestState": "AmgsMN.....2sk4SI" 
}

La réponse contient :

requestState : doit être transmis par le client à l'étape suivante
displayName : ID de courriel extrait du profil de l'utilisateur
method : liste des méthodes inscrites à la méthode EMAIL
factorId : identificateur unique généré pour le facteur en cours d'inscription

Le succès indique que :

La valeur userGUID ou userOcid fournie est valide
L'utilisateur est actif
Le compte utilisateur n'est pas verrouillé
Le facteur EMAIL est activé

Etape 2 : Activer le facteur EMAIL

Cette étape active l'inscription EMAIL pour l'utilisateur, dans une demande PATCH au point de terminaison /mfa/v1/users/{{userGUID}}/factors/{{factorID}}.

Le client doit inclure les attributs suivants :

otpCode: le code reçu par l'utilisateur sur son ID de courriel
requestState : reçu dans la réponse de l'étape 1

Exemple de demande

L'exemple suivant illustre le contenu de la demande PATCH au format JSON :

{
"otpCode":"710130", 
"requestState": "{{requestState}}"
}

Exemple de réponse

L'exemple suivant illustre le contenu de la réponse au format JSON :

{"status":"success"}

Le succès indique que :

OTP est valide
La valeur userGUID ou userOcid fournie est valide
L'utilisateur est actif
Le compte utilisateur n'est pas verrouillé
Le facteur EMAIL est activé et le facteur est inscrit avec succès

Exemples de réponse d'erreur

L'exemple suivant montre le message d'erreur au format JSON lorsque userGUID n'est pas valide. Vous obtenez un code de réponse HTTP 404 si userGUID ou userOcid n'est pas valide.

{
    "status": "failed",
    "ecId": "0d1QwglU0000Fy",
    "cause": [
        {
            "code": "AUTH-3018",
            "message": "User not found."
        }
    ]
}

L'exemple suivant montre le message d'erreur au format JSON lorsque EMAIL est désactivé. Vous obtenez un code de réponse HTTP 401.

{
    "status": "failed",
    "ecId": "0000M00000A",
    "cause": [
        {
            "code": "AUTH-1125",
            "message": "The EMAIL factor has been disabled."
        }
    ]
}

Documentation Oracle Cloud Infrastructure

Utiliser l'API d'authentification à plusieurs facteurs à la demande pour développer une page de connexion personnalisée

Inscription de facteur avec vérification

Extraire les facteurs inscrits d'un utilisateur

Etape 1 : Obtention des facteurs inscrits pour un utilisateur par userGUID

Etape 2 : Obtenir les facteurs inscrits pour un utilisateur à l'aide de filtres

Lancer et vérifier le facteur préféré

Step1 : lancer la vérification du facteur préféré

Etape 2 : Vérifier le facteur préféré

Lancer et vérifier un facteur de sauvegarde

Etape 1 : Lancer et vérifier les questions de sécurité du facteur de sauvegarde

Etape 2 : Lancer et vérifier le facteur de sauvegarde EMAIL

Renvoyer les facteurs de mot de passe à usage unique sans notifier l'utilisateur

Inscription de facteur d'authentification avec vérification de facteur - SMS

Etape 1 : Lancer l'inscription au facteur SMS

Etape 1a : Renvoyer le mot de passe à usage unique

Etape 2 : Activer le facteur SMS

Inscription de facteur d'authentification avec vérification de facteur - Courriel

Etape 1 : Lancer l'inscription au facteur e-mail

Etape 1a : Renvoyer le mot de passe à usage unique

Etape 2 : Activer le facteur EMAIL