Benutzerdefinierte Anmeldeseite mit der On-Demand-MFA-API entwickeln

Dieser Anwendungsfall enthält ein schrittweises Beispiel für die Verwendung der REST-API für Identitätsdomains, um Benutzer zu authentifizieren und eine Multifaktor-Registrierung und -Authentifizierung durchzuführen.

Hinweis

Verwenden Sie diese Authentifizierungs-API nur, wenn Sie Ihre eigene End-to-End-Anmeldeerfahrung erstellen, indem Sie eine benutzerdefinierte Anmeldeanwendung entwickeln, die von Identitätsdomains verwendet werden soll.

Hinweis

Diese Authentifizierungs-API kann nicht zur Integration Ihrer Anwendungen mit Identitätsdomains für Single Sign-On-Zwecke verwendet werden.

Die On Demand-MFA-API basiert auf dem Konzept eines Zustandsrechners. Anforderungsantworten informieren einen Anwendungsclient darüber, was als Nächstes zu tun ist, anstatt zu verlangen, dass Benutzer Cookies von Drittanbietern in ihren Browsern aktivieren. Cookies von Drittanbietern, die in Browsern aktiviert werden, können zu Problemen führen, insbesondere bei B2C-Anwendungen, bei denen das Verhalten von Endbenutzern nicht durchgesetzt werden kann. Die in jeder Anforderungsantwort angegebene requestState wird in der nächsten Anforderung verwendet. Sie stellt dem Client die Informationen zur Verfügung, die er zur Verarbeitung der Anforderung benötigt, und stellt dann die nächste Gruppe von zulässigen Vorgängen bereit.

Die On Demand-MFA-API kann:

Benutzeranmeldung mit vom Administrator aktivierten MFA-Faktoren unterstützen
Verbessern Sie die Sicherheit der kennwortbasierten Authentifizierung mit der Multifaktor-Authentifizierung (MFA), indem Sie zusätzliche Verifizierungen erfordern, wie z. B. einen zeitbasierten Einmal-Passcode oder einen SMS-Passcode.
MFA-Registrierung, MFA-Verifizierung und Verwaltung des Benutzerauthentifizierungsfaktors durchführen.

In diesem Anwendungsfall sind die folgenden Beispielsets enthalten:

Faktoranmeldung mit Verifizierung

Diese Anwendungsfälle stellen Beispielanforderungen mit der REST-API für Identitätsdomains dar, mit der sich ein Benutzer für MFA-Faktoren registrieren kann.

Die folgenden Anwendungsfälle führen Sie durch die Schritte zum Registrieren verschiedener MFA-Faktoren mit der REST-API:

Angemeldete Faktoren eines Benutzers abrufen

Dieser Anwendungsfall enthält ein schrittweises Beispiel für die Verwendung der Verifizierungs-API für Identitätsdomains zum Abrufen der Faktoren, für die ein Benutzer registriert ist.

Bei diesen Schritten wird davon ausgegangen, dass relevante Faktoren von MFA mit Einstellungen für die Multifaktor-Authentifizierung konfigurieren aktiviert sind.

Laden Sie die Collection der Anwendungsbeispiele für die Authentifizierung von Identitätsdomains und die globale Variablendatei aus dem Ordner idcs-factor-enrollment-api im Repository idm-samples GitHub herunter, und importieren Sie sie dann in Postman.

Der in diesem Anwendungsfall zu befolgende Schritt hängt davon ab, ob Sie die Anforderung mit userGUID oder User Name anfordern möchten:

Hinweis

In den Beispielen in diesem Abschnitt wird userGUID in den Anforderungen verwendet. Sie können in Ihren Anforderungen sowohl userGUID als auch userOcid anfordern.

Schritt 1: Registrierte Faktoren für einen Benutzer von userGUID abrufen

Mit diesem Schritt werden die registrierten Faktoren für einen Benutzer basierend auf dem userGUID- oder Benutzernamen abgerufen.

Anforderungsbeispiel

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:


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

Die Antwort enthält die Details userGUID, den bevorzugten Faktor und den registrierten Faktor.

Schritt 2: Registrierte Faktoren für einen Benutzer mit Filtern abrufen

Sie können registrierte Faktoren für einen Benutzer entweder mit dem Benutzernamen oder der Benutzer-GUID abrufen. Die folgenden userIdType-Werte werden akzeptiert:

USER_GUID: Beispiel: Hier muss userId USER_GUID wie "7b3d902ab05b4214" enthalten
USER_NAME: Beispiel: Hier muss userId USER_NAME wie John enthalten.

Anforderungsbeispiel zum Abrufen der registrierten Faktoren basierend auf dem Benutzernamen

Das folgende Beispiel zeigt das Anforderungsbeispiel zum Abrufen der registrierten Factors für einen Benutzer basierend auf ihrem Benutzernamen im JSON-Format:


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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

Die Antwort enthält die Details userGUID, den bevorzugten Faktor und den registrierten Faktor.

Anforderungsbeispiel zum Abrufen der registrierten Faktoren basierend auf Benutzer-GUID

Das folgende Beispiel zeigt das Anforderungsbeispiel zum Abrufen der registrierten Faktoren für einen Benutzer basierend auf ihrer Benutzer-GUID im JSON-Format:


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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

Die Antwort enthält die Details userGUID, den bevorzugten Faktor und den registrierten Faktor.

Bevorzugten Faktor initiieren und prüfen

Dieser Anwendungsfall enthält ein schrittweises Beispiel für die Verwendung der Identitätsdomains "Faktor-Registrierungs-API", um sich bei der Faktorverifizierung für die Multifaktor-Authentifizierung (MFA) anzumelden.

Bei diesen Schritten wird davon ausgegangen, dass relevante Faktoren von MFA mit Einstellungen für die Multifaktor-Authentifizierung konfigurieren aktiviert sind.

Laden Sie die Collection der Anwendungsbeispiele für die Authentifizierung von Identitätsdomains und die globale Variablendatei aus dem Ordner idcs-factor-verification-api im Repository idm-samples GitHub herunter, und importieren Sie sie dann in Postman.

Laden Sie die Collection und die globale Variablendatei aus dem Ordner idcs-factor-verification-api in GitHub herunter, und importieren Sie sie dann in Postman.

Verwenden Sie die folgenden Schritte für den Anwendungsfall. Jeder Schritt enthält Anforderungs- und Antwortbeispiele:

Hinweis

In den Beispielen in diesem Abschnitt wird userGUID in den Anforderungen verwendet. Sie können in Ihren Anforderungen sowohl userGUID als auch userOcid anfordern.

Step1: Verifizierung des bevorzugten Faktors initiieren

Dieser Schritt initiiert die Verifizierung des bevorzugten Faktors eines Benutzers. Wenn Sie die Verifizierungsfaktor-API verwenden müssen, ohne die userGUID anzugeben, können Sie eine eindeutige Benutzer-ID wie den Benutzernamen als userId angeben. Die userIdType in der Anforderung gibt an, welchen Typ von Zugangsdaten der Benutzer als Wert für die userId übergibt. Die folgenden userIdType-Werte werden akzeptiert:

USER_GUID: Beispiel: Hier muss userId USER_GUID wie "7b3d902ab05b4214" enthalten
USER_NAME: Beispiel: Hier muss userId USER_NAME wie John enthalten.

Das Attribut userId enthält den tatsächlichen Wert der übergebenen Benutzerzugangsdaten.

Anforderungsbeispiel

Das folgende Beispiel zeigt die POST-Anforderung an den Endpunkt {{HOST}}/mfa/v1/requests im JSON-Format.

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der POST-Antwort an den Endpunkt {{HOST}}/mfa/v1/requests im JSON-Format, nachdem der bevorzugte Faktor für die bevorzugte ID initiiert wurde:


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

In der Antwort ist der Wert requestId die eindeutige ID, die für diese Anforderung generiert wurde. Nehmen Sie die requestId in jeden nachfolgenden Aufruf auf, um die Faktorverifizierung abzuschließen. factorId ist das bevorzugte Gerät, auf dem es initiiert wurde. method ist der Faktor, den der Benutzer initiiert hat. Die requestState enthält die kontextbezogenen Daten, die zur Verarbeitung der Anforderung erforderlich sind.

In diesem Beispiel wird eine otpCode (bei SMS und EMAIL-Faktor) per SMS an das Mobilgerät des Benutzers gesendet.

Schritt 2: Bevorzugten Faktor prüfen

Dieser Schritt prüft den Faktor, indem der otpCode in einer PATCH-Anforderung an {{HOST}}/mfa/v1/requests/{{requestId}} übergeben wird.

Der Client muss die folgenden Attribute enthalten:

otpCode: den vom Benutzer auf seinem Gerät empfangenen Code
requestState: in der Antwort von Schritt 1 empfangen
requestId: in der Antwort von Schritt 1 empfangen

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der PATCH-Anforderung im JSON-Format:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

{"status":"success"}

Der Erfolg gibt an, dass die Verifizierung erfolgreich war.

Backupfaktor initiieren und prüfen

Dieser Anwendungsfall enthält ein schrittweises Beispiel für die Verwendung der Verifizierungs-API für Identitätsdomains, um die Faktorverifizierung des Backupfaktors abzuschließen.

Bei diesen Schritten wird davon ausgegangen, dass relevante Faktoren von MFA mit Einstellungen für die Multifaktor-Authentifizierung konfigurieren aktiviert sind.

Verwenden Sie die folgenden Schritte für den Anwendungsfall. Jeder Schritt enthält Anforderungs- und Antwortbeispiele:

Hinweis

In den Beispielen in diesem Abschnitt wird userGUID in den Anforderungen verwendet. Sie können in Ihren Anforderungen sowohl userGUID als auch userOcid anfordern.

Schritt 1: Sicherheitsfragen zum Backupfaktor initiieren und prüfen

Dieser Schritt initiiert die Verifizierung des Backupfaktors eines Benutzers. Der Client muss in der Anforderung sowohl factorId als auch method angeben. Wenn Sie die Verifizierungsfaktor-API verwenden müssen, ohne die userGUID anzugeben, können Sie eine eindeutige Benutzer-ID wie den Benutzernamen als userId angeben. Die userIdType in der Anforderung gibt an, welchen Typ von Zugangsdaten der Benutzer als Wert für die userId übergibt. Die folgenden userIdType-Werte werden akzeptiert:

USER_GUID: Beispiel: Hier muss userId USER_GUID wie "7b3d902ab05b4214" enthalten.
USER_NAME: Beispiel: Hier muss userId USER_NAME wie Joe John enthalten.

Das Attribut userId enthält den tatsächlichen Wert der übergebenen Benutzerzugangsdaten.

Eine Liste der angemeldeten Faktoren und ihrer IDs für einen Benutzer finden Sie im Anwendungsfall Angemeldete Faktoren eines Benutzers abrufen. In diesem Beispiel ist der gewählte Backup-Faktor "Sicherheitsfragen".

Anforderungsbeispiel zum Initiieren von Sicherheitsfragen für Backupfaktor

Das folgende Beispiel zeigt den Inhalt der POST-Anforderung an den {{HOST}}/mfa/v1/requests/-Endpunkt im JSON-Format:

Hinweis

Die bevorzugte factorId enthält die eindeutige ID des bevorzugten Faktors. Bei SECURITY_QUESTIONS wird die feste Zeichenfolge "SecurityQuestions" verwendet.

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

In der Antwort ist der Wert requestId die eindeutige ID, die für diese Anforderung generiert wurde. Nehmen Sie die requestId in jeden nachfolgenden Aufruf auf, um die Faktorverifizierung abzuschließen. Die requestState enthält kontextbezogene Daten, die zur Verarbeitung der Anforderung erforderlich sind.

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format für die Backupmethode 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?"
        }
    ]
}

In der Antwort ist der Wert requestId die eindeutige ID, die für diese Anforderung generiert wurde. Nehmen Sie die requestId in jeden nachfolgenden Aufruf auf, um die Faktorverifizierung abzuschließen. Die requestState enthält kontextbezogene Daten, die zur Verarbeitung der Anforderung erforderlich sind. In diesem Beispiel wird eine Frage aus der Liste der angemeldeten Fragen zurückgesendet, auf die der Benutzer antworten muss.

Anforderungsbeispiel zur Prüfung von Sicherheitsfragen für Backupfaktor

Dieser Schritt prüft den Backupfaktor, indem die Antwort auf die Sicherheitsfrage in einer PATCH-Anforderung an {{HOST}}/mfa/v1/requests/{{requestID}} übergeben wird. Der Client muss die folgenden Attribute enthalten:

requestState: in der Schritt-1-Antwort empfangen
securityQuestions id/answers: Wird vom Benutzer bei der Anmeldung definiert

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der PATCH-Anforderung im JSON-Format für SECURITY_QUESTIONS:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

{"status":"success"}

Der Erfolg gibt an, dass die Verifizierung erfolgreich war.

Schritt 2: Backupfaktor EMAIL starten und prüfen

Dieser Schritt initiiert die Verifizierung eines Backupfaktors EMAIL.

Anforderungsbeispiel zum Initiieren des E-Mail-Faktors

Das folgende Beispiel zeigt das Anforderungsbeispiel im JSON-Format für die bevorzugte Methode "EMAIL":

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

Antwortbeispiel

Das folgende Beispiel zeigt das Antwortbeispiel zum Initiieren des EMAIL-Faktors im JSON-Format:

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

Anforderungsbeispiel zur Prüfung des E-Mail-Faktors

Das folgende Beispiel zeigt die PATCH-Anforderung im JSON-Format für den EMAIL-Faktor:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format, um den EMAIL-Faktor zu prüfen:

{"status":"success"}

Der Erfolg gibt an, dass die Verifizierung erfolgreich war.

OTP-Faktoren ohne Benachrichtigung des Benutzers zurückgeben

Dieser Anwendungsfall enthält ein Beispiel dafür, wie Sie die On Demand-MFA-API initiieren, um Einmal-Passcode-(OTP-)Faktoren (SMS oder E-Mail oder Telefonanruf) in einer Antwort zurückzugeben, ohne den Benutzer zu benachrichtigen.

Bei diesen Schritten wird davon ausgegangen, dass relevante Faktoren von MFA mit Einstellungen für Multifaktor-Authentifizierung konfigurieren aktiviert werden.

Anforderungs-Payload


Attribut	Unterstützte Werte/Beispielwerte	Mehrwertig	Nutzungsdetails
`userFlowControlledByExternalClient`	True / False	False	Diese Option setzen auf `true` und das OTP wird in der Antwort in dem angegebenen verschlüsselten Format zurückgegeben. Hinweis: Das für die Verschlüsselung verwendete Zertifikat wird im Voraus in die Anwendung hochgeladen und mit dem Attribut `x5t` im Anforderungsbeispiel wie unten beschrieben referenziert.
x5t	Zeichenfolge / X509 SHA-1 Zertifikat-Thumbprint		Wenn angegeben, verwendet der Service dieses hochgeladene Zertifikat zur Verschlüsselung der OTP-Daten. Hinweis: Das Attribut "x5t" muss mit dem hochgeladenen Zertifikat übereinstimmen.

Anforderungsbeispiel

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

Antwort-Payload


Attribut	Unterstützte Werte/Beispielwerte	Mehrwertig	Nutzungsdetails
`otp`	Zuordnung `"otp": { "value": "IMCw==", "alg": "RSAES-OAEP", "x5t": "<certificate thumbprint>" }`	False	Wenn das Attribut in der Antwort vorhanden ist, enthält es das verschlüsselte OTP mit den folgenden Details. Wert: Verschlüsselter Wert. alg: Algorithmus für die Verschlüsselung. x5t: SHA-1 X509 Thumbprint des Zertifikats, das für die Verschlüsselung verwendet wird.

Antwortbeispiel

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

Authentifizierungsfaktoranmeldung mit Faktorverifizierung - SMS

Bei diesen Schritten wird davon ausgegangen, dass relevante Faktoren von MFA mit Einstellungen für die Multifaktor-Authentifizierung konfigurieren aktiviert sind.

Verwenden Sie die folgenden Schritte für den Anwendungsfall. Jeder Schritt enthält Anforderungs- und Antwortbeispiele:

Hinweis

In den Beispielen in diesem Abschnitt wird userGUID in den Anforderungen verwendet. Sie können in Ihren Anforderungen sowohl userGUID als auch userOcid anfordern.

Schritt 1: SMS-Faktoranmeldung initiieren

Dieser Schritt initiiert die SMS-Registrierung. Der Client muss die folgenden Attribute enthalten:

method: Definiert die Anmeldung beim SMS-Faktor
phoneNumber: Definiert die Telefonnummer, an die der SMS-Text gesendet wird
countryCode: Definiert die Landeskennzahl der Telefonnummer, an die der SMS-Text gesendet wird

Anforderungsbeispiel

Das folgende Beispiel zeigt die POST-Anforderung an den Endpunkt {{HOST}}/mfa/v1/users/{{userGUID}}/factors im JSON-Format:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

displayName ist die Mobiltelefonnummer. Eine otpCode wird an das Mobilgerät des Benutzers gesendet, mit dem die Registrierung abgeschlossen wird.

Schritt 1a: OTP erneut senden

Wenn der Benutzer das OTP nicht erhält, wird in diesem Beispiel gezeigt, wie Sie das erneute Senden eines OTPs anfordern. Der Client muss die folgenden Attribute enthalten:

requestState: in der Schritt-1-Antwort empfangen

resendOtp: Boolescher Wert, der angibt, dass das OTP empfangen wird

Anforderungsbeispiel

Das folgende Beispiel zeigt die PATCH-Anforderung an den Endpunkt {{HOST}}/mfa/v1/users/{{userGUID}}/factors/{{factorID}} im JSON-Format:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

Die Antwort enthält die folgenden Parameter:

requestState:, die vom Client im nächsten Schritt übergeben werden soll
displayName: ist die registrierte Mobiltelefonnummer.
method: SMS-Faktormethode
Eindeutige ID factorId:, die für den zu registrierenden Faktor generiert wird

Erfolg bedeutet:

Die angegebene userGUID ist gültig
Der Benutzer ist aktiv
Benutzeraccount ist nicht gesperrt
Der SMS-Faktor ist aktiviert

Schritt 2: SMS-Faktor aktivieren

In diesem Schritt wird die SMS-Registrierung für den Benutzer in einer PATCH-Anforderung an den Endpunkt /mfa/v1/users/{{userGUID}}/factors/{{factorID}} aktiviert.

Der Client muss die folgenden Attribute enthalten:

otpCode: den vom Benutzer auf seinem Gerät empfangenen Code
requestState: in der Antwort von Schritt 1 empfangen

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der PATCH-Anforderung im JSON-Format:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

{"status":"success"}

Erfolg bedeutet:

OTP ist gültig
Die angegebene userGUID ist gültig
Der Benutzer ist aktiv
Benutzeraccount ist nicht gesperrt
Der SMS-Faktor ist aktiviert, und der Faktor wurde erfolgreich registriert

Fehlerantwortbeispiele

Das folgende Beispiel zeigt die Fehlermeldung im JSON-Format, wenn die userGUID ungültig ist. Sie erhalten einen HTTP-Antwortcode von 404, wenn userGUID ungültig ist.

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

Das folgende Beispiel zeigt die Fehlermeldung im JSON-Format, wenn der Benutzer gesperrt ist. Sie erhalten einen HTTP-Antwortcode von 401.

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

Authentifizierungsfaktoranmeldung mit Faktorprüfung - E-Mail

Bei diesen Schritten wird davon ausgegangen, dass relevante Faktoren von MFA mit Einstellungen für die Multifaktor-Authentifizierung konfigurieren aktiviert sind.

Verwenden Sie die folgenden Schritte für den Anwendungsfall. Jeder Schritt enthält Anforderungs- und Antwortbeispiele:

Hinweis

In den Beispielen in diesem Abschnitt wird userGUID in den Anforderungen verwendet. Sie können in Ihren Anforderungen sowohl userGUID als auch userOcid anfordern.

Schritt 1: E-Mail-Faktoranmeldung initiieren

Dieser Schritt initiiert die E-Mail-Anmeldung. Der Client muss das folgende Attribut enthalten:

method: Definiert die Anmeldung bei E-Mail. Der Benutzer wird die E-Mail-ID nicht übergeben. Die primäre E-Mail-ID wird automatisch aus dem Profil des Benutzers abgerufen.

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der POST-Anforderung an den Endpunkt {{HOST}}/mfa/v1/users/{{userGUID}}/factors im JSON-Format:

{ 
"method": "EMAIL",
}

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

Eine otpCode wird an die E-Mail-ID des Benutzers gesendet, mit der die Registrierung abgeschlossen wird.

Die Antwort enthält:

requestState:, die vom Client im nächsten Schritt übergeben werden soll
displayName: E-Mail-ID des angemeldeten Benutzers.
method: EMAIL-Faktormethode

Erfolg bedeutet:

Die Faktoranmeldung wurde initiiert.

Schritt 1a: OTP erneut senden

Das folgende Beispiel zeigt die PATCH-Anforderung an den Endpunkt {{HOST}}/mfa/v1/users/{{userGUID}}/factors/{{factorID}} im JSON-Format.

Wenn der Benutzer das OTP nicht erhält, wird in diesem Beispiel gezeigt, wie Sie das erneute Senden eines OTPs anfordern. Der Client muss die folgenden Attribute enthalten:

requestState: in der Schritt-1-Antwort empfangen
resendOtp:, um anzugeben, dass das OTP empfangen wird

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der PATCH-Anforderung im JSON-Format:

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

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

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

Die Antwort enthält:

requestState: Wird vom Client im nächsten Schritt übergeben
displayName: E-Mail-ID aus Benutzerprofil abgerufen
method: Die Liste der Methoden, die bei der EMAIL-Methode registriert werden
factorId: Eindeutige ID, die für den Faktor generiert wird, der registriert wird

Erfolg bedeutet:

Die angegebene userGUID oder userOcid ist gültig
Der Benutzer ist aktiv
Benutzeraccount ist nicht gesperrt
Der EMAIL-Faktor ist aktiviert

Schritt 2: EMAIL-Faktor aktivieren

In diesem Schritt wird die EMAIL-Registrierung für den Benutzer in einer PATCH-Anforderung an den Endpunkt /mfa/v1/users/{{userGUID}}/factors/{{factorID}} aktiviert.

Der Client muss die folgenden Attribute enthalten:

otpCode: den Code, den der Benutzer in seiner E-Mail-ID erhalten hat
requestState: in der Antwort von Schritt 1 empfangen

Anforderungsbeispiel

Das folgende Beispiel zeigt den Inhalt der PATCH-Anforderung im JSON-Format:

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

Antwortbeispiel

Das folgende Beispiel zeigt den Inhalt der Antwort im JSON-Format:

{"status":"success"}

Erfolg bedeutet:

OTP ist gültig
Die angegebene userGUID oder userOcid ist gültig
Der Benutzer ist aktiv
Benutzeraccount ist nicht gesperrt
Der EMAIL-Faktor ist aktiviert, und der Faktor wurde erfolgreich registriert

Fehlerantwortbeispiele

Das folgende Beispiel zeigt die Fehlermeldung im JSON-Format, wenn die userGUID ungültig ist. Sie erhalten einen HTTP-Antwortcode von 404, wenn userGUID oder userOcid ungültig ist.

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

Das folgende Beispiel zeigt die Fehlermeldung im JSON-Format, wenn EMAIL deaktiviert ist. Sie erhalten einen HTTP-Antwortcode von 401.

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

Oracle Cloud Infrastructure - Dokumentation

Benutzerdefinierte Anmeldeseite mit der On-Demand-MFA-API entwickeln

Faktoranmeldung mit Verifizierung

Angemeldete Faktoren eines Benutzers abrufen

Schritt 1: Registrierte Faktoren für einen Benutzer von userGUID abrufen

Schritt 2: Registrierte Faktoren für einen Benutzer mit Filtern abrufen

Bevorzugten Faktor initiieren und prüfen

Step1: Verifizierung des bevorzugten Faktors initiieren

Schritt 2: Bevorzugten Faktor prüfen

Backupfaktor initiieren und prüfen

Schritt 1: Sicherheitsfragen zum Backupfaktor initiieren und prüfen

Schritt 2: Backupfaktor EMAIL starten und prüfen

OTP-Faktoren ohne Benachrichtigung des Benutzers zurückgeben

Authentifizierungsfaktoranmeldung mit Faktorverifizierung - SMS

Schritt 1: SMS-Faktoranmeldung initiieren

Schritt 1a: OTP erneut senden

Schritt 2: SMS-Faktor aktivieren

Authentifizierungsfaktoranmeldung mit Faktorprüfung - E-Mail

Schritt 1: E-Mail-Faktoranmeldung initiieren

Schritt 1a: OTP erneut senden

Schritt 2: EMAIL-Faktor aktivieren