オンデマンドMFA APIを使用したカスタム・サインイン・ページの開発

このユースケースでは、アイデンティティ・ドメインREST APIを使用してユーザーを認証し、マルチファクタ登録および認証を実行するステップ・バイ・ステップの例を示します。

ノート

この認証APIを使用するのは、アイデンティティ・ドメインで使用するカスタム・サインイン・アプリケーションを開発して、独自のエンドツーエンド・ログイン・エクスペリエンスを構築する場合のみです。

ノート

この認証APIを使用して、シングル・サインオンのためにアプリケーションをアイデンティティ・ドメインと統合することはできません。

オンデマンドMFA APIは、状態マシンの概念に基づいています。リクエスト・レスポンスでは、ユーザーがブラウザでサードパーティCookieを有効にする必要なく、次に実行する必要がある操作をアプリケーション・クライアントに通知します。サードパーティCookieは、特にエンド・ユーザーの動作に対する制御を強制できないB2Cアプリケーションで問題を引き起こす可能性があります。各リクエスト・レスポンスで提供されるrequestStateは、次のリクエストで使用され、リクエストの処理に必要な情報をクライアントに提供してから、許可される次の操作セットを提供します。

On Demand MFA APIでは:

管理者によって有効化されたMFAファクタへのユーザー登録のサポート
時間ベースのワンタイム・パスコードやSMSパスコードの使用などの追加の検証を必要とすることで、多要素認証(MFA)を使用したパスワードベース認証のセキュリティを強化します。
MFA登録、MFA検証およびユーザー認証ファクタ管理を実行します。

このユースケースには、次の例のセットが含まれています:

検証ありのファクタ登録

ここでは、ユーザーがMFAファクタに登録できるようにするアイデンティティ・ドメインREST APIを使用したリクエストの例を示します。

次のユースケースでは、REST APIを使用して様々なMFAファクタを登録するステップを説明します:

ユーザーの登録済ファクタのフェッチ

このユースケースでは、アイデンティティ・ドメイン検証APIを使用して、ユーザーが登録されているファクタをフェッチするステップ・バイ・ステップの例を示します。

これらのステップでは、「マルチファクタ認証設定の構成」を使用して、MFAの関連ファクタを有効にすることを前提としています。

idm-samples GitHubリポジトリ内のidcs-factor-enrollment-apiフォルダから、アイデンティティ・ドメイン認証のユースケース・サンプル・コレクションおよびグローバル変数ファイルをダウンロードし、Postmanにインポートします。

このユースケースで実行するステップは、userGUIDとUser Nameのどちらを使用してリクエストするかによって異なります:

ノート

この項の例では、リクエストでuserGUIDを使用しています。リクエストでuserGUIDとuserOcidの両方をリクエストできます。

ステップ1: userGUIDによるユーザーの登録済ファクタの取得

このステップでは、userGUIDまたはユーザー名に基づいて、ユーザーの登録済ファクタを取得します。

リクエストの例

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

レスポンスの例

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"
            ]
        }
    ]
}

レスポンスには、userGUID、優先ファクタおよび登録済ファクタの詳細が含まれます。

ステップ2: フィルタを使用したユーザーの登録済ファクタの取得

ユーザー名またはユーザーGUIDのいずれかを使用して、ユーザーの登録済ファクタを取得できます。使用可能なuserIdType値は次のとおりです:

USER_GUID- たとえば、userIdには、7b3d902ab05b4214などのUSER_GUIDを含める必要があります
USER_NAME- たとえば、userIdには、JohnなどのUSER_NAMEを含める必要があります。

ユーザー名に基づいて登録済ファクタをフェッチする要求の例

JSON形式のユーザー名に基づいてユーザーの登録済ファクタを取得するリクエストの例を次に示します:


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

レスポンスの例

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"
            ]
        }
    ]
}

レスポンスには、userGUID、優先ファクタおよび登録済ファクタの詳細が含まれます。

ユーザーGUIDに基づいて登録済ファクタをフェッチする要求例

JSON形式のユーザーGUIDに基づいてユーザーの登録済ファクタを取得するリクエストの例を示します:


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

レスポンスの例

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"
            ]
        }
    ]
}

レスポンスには、userGUID、優先ファクタおよび登録済ファクタの詳細が含まれます。

優先ファクタの開始と検証

このユースケースでは、アイデンティティ・ドメイン・ファクタ登録APIを使用して、マルチファクタ認証(MFA)にファクタ検証を登録するステップ・バイ・ステップの例を示します。

これらのステップでは、「マルチファクタ認証設定の構成」を使用して、MFAの関連ファクタを有効にすることを前提としています。

idm-samples GitHubリポジトリ内のidcs-factor-verification-apiフォルダから、アイデンティティ・ドメイン認証ユースケース・サンプル・コレクションおよびグローバル変数ファイルをダウンロードし、Postmanにインポートします。

GitHub内のidcs-factor-verification-apiフォルダから、コレクションおよびグローバル変数ファイルをダウンロードし、Postmanにインポートします。

この使用例では、次のステップを使用します。各ステップには、リクエストおよびレスポンスの例が含まれます:

ノート

この項の例では、リクエストでuserGUIDを使用しています。リクエストでuserGUIDとuserOcidの両方をリクエストできます。

Step1: 優先ファクタの検証の開始

このステップでは、ユーザーの優先ファクタの検証を開始します。userGUIDを指定せずにファクタ検証APIを使用する必要がある場合は、ユーザー名などのユーザーの一意のIDをuserIdとして指定できます。リクエスト内のuserIdTypeは、ユーザーがuserIdの値として渡す資格証明のタイプを示します。使用可能なuserIdType値は次のとおりです:

USER_GUID - たとえば、userIdには、7b3d902ab05b4214などのUSER_GUIDを含める必要があります
USER_NAME - たとえば、userIdには、JohnなどのUSER_NAMEを含める必要があります。

userId属性には、渡されるユーザー資格証明の実際の値が含まれます。

リクエストの例

{{HOST}}/mfa/v1/requestsエンドポイントに対するJSON形式のPOSTリクエストの例を次に示します。

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

レスポンスの例

優先IDで優先ファクタを開始した後の、{{HOST}}/mfa/v1/requestsエンドポイントに対するJSON形式のPOSTレスポンスのコンテンツの例を次に示します:


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

レスポンスでは、requestId値は、このリクエストに対して生成された一意の識別子です。後続のすべてのコールにrequestIdを含めて、ファクタの検証を完了します。factorIdは、それが開始された優先デバイスです。methodは、ユーザーが開始したファクタです。requestStateには、リクエストの処理に必要なコンテキスト・データが含まれます。

この例では、otpCode (SMSおよびEMAILファクタの場合)がSMSを使用してユーザーのモバイル・デバイスに送信されます。

ステップ2: 優先ファクタの検証

このステップでは、PATCHリクエストでotpCodeを{{HOST}}/mfa/v1/requests/{{requestId}}に渡してファクタを検証します。

クライアントには次の属性が含まれている必要があります:

otpCode:ユーザーがデバイスで受信したコード
requestState: ステップ1のレスポンスで受信
requestId: ステップ1のレスポンスで受信

リクエストの例

JSON形式のPATCHリクエストのコンテンツの例を次に示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

{"status":"success"}

「成功」は、検証が成功したことを示します。

バックアップ・ファクタの開始と検証

このユースケースでは、アイデンティティ・ドメイン検証APIを使用して、バックアップ・ファクタのファクタ検証を完了するステップ・バイ・ステップの例を示します。

これらのステップでは、「マルチファクタ認証設定の構成」を使用して、MFAの関連ファクタを有効にすることを前提としています。

この使用例では、次のステップを使用します。各ステップには、リクエストおよびレスポンスの例が含まれます:

ノート

この項の例では、リクエストでuserGUIDを使用しています。リクエストでuserGUIDとuserOcidの両方をリクエストできます。

ステップ1: バックアップ・ファクタのセキュリティ質問の開始と検証

このステップでは、ユーザーのバックアップ・ファクタの検証を開始します。クライアントは、リクエストでfactorIdとmethodの両方を指定する必要があります。userGUIDを指定せずにファクタ検証APIを使用する必要がある場合は、ユーザー名などのユーザーの一意のIDをuserIdとして指定できます。リクエスト内のuserIdTypeは、ユーザーがuserIdの値として渡す資格証明のタイプを示します。使用可能なuserIdType値は次のとおりです:

USER_GUID - たとえば、userIdには、"7b3d902ab05b4214"などのUSER_GUIDを含める必要があります。
USER_NAME - たとえば、userIdには、Joe JohnなどのUSER_NAMEを含める必要があります。

userId属性には、渡されるユーザー資格証明の実際の値が含まれます。

ユーザーの登録ファクタとそのIDのリストを取得するには、「ユーザーの登録ファクタのフェッチ」ユースケースを参照してください。この例では、選択されたバックアップ・ファクタはセキュリティ質問です。

バックアップ・ファクタのセキュリティ質問を開始するリクエストの例

次の例に、JSON形式の{{HOST}}/mfa/v1/requests/エンドポイントに対するPOSTリクエストのコンテンツを示します:

ノート

優先factorIdには、優先ファクタの一意のIDが含まれます。SECURITY_QUESTIONSの場合、固定文字列"SecurityQuestions"が含まれます。

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

レスポンスでは、requestId値は、このリクエストに対して生成された一意の識別子です。後続のすべてのコールにrequestIdを含めて、ファクタの検証を完了します。requestStateには、リクエストの処理に必要なコンテキスト・データが含まれます。

レスポンスの例

バックアップ・メソッドSEQURITY_QUESTIONSのJSON形式のレスポンスのコンテンツの例を次に示します:

{
    "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?"
        }
    ]
}

レスポンスでは、requestId値は、このリクエストに対して生成された一意の識別子です。後続のすべてのコールにrequestIdを含めて、ファクタの検証を完了します。requestStateには、リクエストの処理に必要なコンテキスト・データが含まれます。この例では、ユーザーが回答する必要がある登録済の質問のリストから質問が返信されます。

バックアップ・ファクタのセキュリティ質問を検証するリクエストの例

このステップでは、PATCHリクエストのセキュリティ質問への回答を{{HOST}}/mfa/v1/requests/{{requestID}}に渡して、バックアップ・ファクタを検証します。クライアントには次の属性が含まれている必要があります:

requestState:ステップ1のレスポンスで受信した
securityQuestions id/answers: 登録時にユーザーによって定義されます

リクエストの例

次の例に、SECURITY_QUESTIONSのJSON形式のPATCHリクエストのコンテンツを示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

{"status":"success"}

「成功」は、検証が成功したことを示します。

ステップ2: バックアップ・ファクタEMAILの開始と検証

このステップでは、バックアップ・ファクタEMAILの検証を開始します。

EMAILファクタを開始するリクエストの例

優先メソッド"EMAIL"に対するJSON形式のリクエストの例を次に示します:

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

レスポンスの例

EMAILファクタを開始するためのJSON形式のレスポンスの例を示します:

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

EMAILファクタを検証する要求の例

次の例は、EMAILファクタのJSON形式のPATCHリクエストを示しています:

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

レスポンスの例

次の例に、EMAILファクタを検証するためのJSON形式のレスポンスのコンテンツを示します:

{"status":"success"}

「成功」は、検証が成功したことを示します。

ユーザーに通知せずにOTPファクタを返す

このユースケースでは、ワンタイム・パスコード(OTP)ファクタ(SMS、電子メールまたは通話)をユーザーに通知することなくレスポンスで返すOn Demand MFA APIを開始する例を示します。

これらのステップでは、「多要素認証設定の構成」を使用して、MFAの関連ファクタを有効にすることを前提としています。

リクエスト・ペイロード


属性	サポートされる値/サンプル値	複数値	使用量の詳細
`userFlowControlledByExternalClient`	true/false	False	このオプションの設定 `true` OTPは、指定された暗号化形式でレスポンスに返されます。ノート: 暗号化に使用される証明書は事前にアプリケーションにアップロードされ、次に示すように、リクエストの例で`x5t`属性を使用して参照されます。
x5t	文字列/X509 SHA-1証明書サムプリント		指定した場合、サービスは、アップロードされたこの証明書を使用してOTPデータを暗号化します。ノート: "x5t"属性は、アップロードされた証明書と一致する必要があります。

リクエストの例

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

レスポンス・ペイロード


属性	サポートされる値/サンプル値	複数値	使用量の詳細
`otp`	マップ `"otp": { "value": "IMCw==", "alg": "RSAES-OAEP", "x5t": "<certificate thumbprint>" }`	False	レスポンスに存在する場合、属性には、暗号化されたOTPに次の詳細が含まれます。 value: 暗号化された値。 alg: 暗号化に使用されるアルゴリズム。 x5t: SHA-1 X509暗号化に使用される証明書のサムプリント

レスポンスの例

{
    "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>"
           }
}

ファクタ検証による認証ファクタ登録-SMS

これらのステップでは、「マルチファクタ認証設定の構成」を使用して、MFAの関連ファクタを有効にすることを前提としています。

この使用例では、次のステップを使用します。各ステップには、リクエストおよびレスポンスの例が含まれます:

ノート

この項の例では、リクエストでuserGUIDを使用しています。リクエストでuserGUIDとuserOcidの両方をリクエストできます。

ステップ1: SMSファクタ登録の開始

このステップでは、SMS登録を開始します。クライアントには次の属性が含まれている必要があります:

method: SMSファクタへの登録を定義します
phoneNumber: SMSテキストが送信される電話番号を定義します
countryCode: SMSテキストが送信される電話番号の国コードを定義します

リクエストの例

{{HOST}}/mfa/v1/users/{{userGUID}}/factorsエンドポイントに対するJSON形式のPOSTリクエストの例を次に示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

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

displayNameはモバイル番号です。otpCodeは、登録を完了するために使用されるユーザーのモバイル・デバイスに送信されます。

ステップ1a: OTPの再送信

ユーザーがOTPを受信しない場合、この例はOTPの再送信をリクエストする方法を示しています。クライアントには次の属性が含まれている必要があります:

requestState:ステップ1のレスポンスで受信した

resendOtp: OTPを受信したことを示すブール

リクエストの例

JSON形式の{{HOST}}/mfa/v1/users/{{userGUID}}/factors/{{factorID}}エンドポイントに対するPATCHリクエストの例を次に示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

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

レスポンスには次のパラメータが含まれています:

requestState:次のステップでクライアントから渡される必要があります
displayName:登録されるモバイル番号です
method: SMSファクタ・メソッド
factorId:登録されるファクタに対して生成される一意の識別子

「成功」は次の内容を示します:

指定されたuserGUIDは有効です
ユーザーがアクティブです
ユーザー・アカウントがロックされていません
SMSファクタが有効です

ステップ2: SMSファクタのアクティブ化

このステップでは、/mfa/v1/users/{{userGUID}}/factors/{{factorID}}エンドポイントへのPATCHリクエストで、ユーザーのSMS登録をアクティブ化します。

クライアントには次の属性が含まれている必要があります:

otpCode:ユーザーがデバイスで受信したコード
requestState: ステップ1のレスポンスで受信

リクエストの例

JSON形式のPATCHリクエストのコンテンツの例を次に示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

{"status":"success"}

「成功」は次の内容を示します:

OTPは有効です
指定されたuserGUIDは有効です
ユーザーがアクティブです
ユーザー・アカウントがロックされていません
SMSファクタが有効で、ファクタが正常に登録されています

エラー・レスポンスの例

userGUIDが無効な場合のJSON形式のエラー・メッセージの例を次に示します。userGUIDが無効な場合、404 HTTPレスポンス・コードが返されます。

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

ユーザーがロックされている場合のJSON形式のエラー・メッセージの例を次に示します。401 HTTPレスポンス・コードが返されます。

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

ファクタ検証による認証ファクタ登録-Eメール

これらのステップでは、「マルチファクタ認証設定の構成」を使用して、MFAの関連ファクタを有効にすることを前提としています。

この使用例では、次のステップを使用します。各ステップには、リクエストおよびレスポンスの例が含まれます:

ノート

この項の例では、リクエストでuserGUIDを使用しています。リクエストでuserGUIDとuserOcidの両方をリクエストできます。

ステップ1: 電子メール・ファクタ登録の開始

このステップでは、電子メール登録を開始します。クライアントには次の属性が含まれている必要があります:

method: 電子メールに登録するように定義します。ユーザーは電子メールIDを渡しません。プライマリ電子メールIDは、ユーザーのプロファイルから自動的にフェッチされます。

リクエストの例

{{HOST}}/mfa/v1/users/{{userGUID}}/factorsエンドポイントに対するJSON形式のPOSTリクエストのコンテンツの例を次に示します:

{ 
"method": "EMAIL",
}

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

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

otpCodeは、登録を完了するために使用されるユーザーの電子メールIDに送信されます。

レスポンスの内容は次のとおりです:

requestState:次のステップでクライアントから渡される必要があります
displayName:登録ユーザーの電子メールID
method: EMAILファクタ・メソッド

「成功」は次の内容を示します:

ファクタ登録が開始されました。

ステップ1a: OTPの再送信

JSON形式の{{HOST}}/mfa/v1/users/{{userGUID}}/factors/{{factorID}}エンドポイントに対するPATCHリクエストの例を次に示します。

requestState:ステップ1のレスポンスで受信した
resendOtp: OTPを受信したことを示します

リクエストの例

JSON形式のPATCHリクエストのコンテンツの例を次に示します:

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

JSON形式のレスポンスのコンテンツの例を次に示します:

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

レスポンスの内容は次のとおりです:

requestState: これは、次のステップでクライアントから渡される必要があります
displayName: ユーザーのプロファイルからフェッチされる電子メールID
method: EMAILメソッドに登録されるメソッドのリスト
factorId: 登録されるファクタに対して生成される一意の識別子

「成功」は次の内容を示します:

指定されたuserGUIDまたはuserOcidは有効です
ユーザーがアクティブです
ユーザー・アカウントがロックされていません
EMAILファクタが有効です

ステップ2: EMAILファクタのアクティブ化

このステップでは、/mfa/v1/users/{{userGUID}}/factors/{{factorID}}エンドポイントへのPATCHリクエストで、ユーザーのEMIL登録をアクティブ化します。

クライアントには次の属性が含まれている必要があります:

otpCode:ユーザーが電子メールIDで受信したコード
requestState: ステップ1のレスポンスで受信

リクエストの例

JSON形式のPATCHリクエストのコンテンツの例を次に示します:

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

レスポンスの例

JSON形式のレスポンスのコンテンツの例を次に示します:

{"status":"success"}

「成功」は次の内容を示します:

OTPは有効です
指定されたuserGUIDまたはuserOcidは有効です
ユーザーがアクティブです
ユーザー・アカウントがロックされていません
EMAILファクタが有効で、ファクタが正常に登録されています

エラー・レスポンスの例

userGUIDが無効な場合のJSON形式のエラー・メッセージの例を次に示します。userGUIDまたはuserOcidが無効な場合、404 HTTPレスポンス・コードが返されます。

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

EMAILが無効な場合のJSON形式のエラー・メッセージの例を次に示します。401 HTTPレスポンス・コードが返されます。

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

Oracle Cloud Infrastructureドキュメント

オンデマンドMFA APIを使用したカスタム・サインイン・ページの開発

検証ありのファクタ登録

ユーザーの登録済ファクタのフェッチ

ステップ1: userGUIDによるユーザーの登録済ファクタの取得

ステップ2: フィルタを使用したユーザーの登録済ファクタの取得

優先ファクタの開始と検証

Step1: 優先ファクタの検証の開始

ステップ2: 優先ファクタの検証

バックアップ・ファクタの開始と検証

ステップ1: バックアップ・ファクタのセキュリティ質問の開始と検証

ステップ2: バックアップ・ファクタEMAILの開始と検証

ユーザーに通知せずにOTPファクタを返す

ファクタ検証による認証ファクタ登録-SMS

ステップ1: SMSファクタ登録の開始

ステップ1a: OTPの再送信

ステップ2: SMSファクタのアクティブ化

ファクタ検証による認証ファクタ登録-Eメール

ステップ1: 電子メール・ファクタ登録の開始

ステップ1a: OTPの再送信

ステップ2: EMAILファクタのアクティブ化