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 zur Authentifizierung von Benutzern sowie zur Registrierung und Authentifizierung von Multifaktor-Instanzen.

Hinweis

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

Hinweis

Mit dieser Authentifizierungs-API können Sie Ihre Anwendungen nicht zu Single Sign-On-Zwecken in Identitätsdomains integrieren.

Die On Demand-MFA-API basiert auf dem Konzept eines Zustandsrechners. Anforderungsantworten informieren einen Anwendungsclient darüber, was als Nächstes getan werden muss, anstatt dass Benutzer Cookies von Drittanbietern in ihren Browsern aktivieren müssen. Cookies von Drittanbietern, die in Browsern aktiviert sind, können Probleme verursachen, insbesondere für B2C-Anwendungen, bei denen die Kontrolle über das Verhalten der Endbenutzer nicht durchgesetzt werden kann. Die in jeder Anforderungsantwort angegebene requestState wird in der nächsten Anforderung verwendet, sodass der Client die Informationen erhält, die er zur Verarbeitung der Anforderung benötigt, und dann die nächste zulässige Vorgangsgruppe bereitstellt.

Die On Demand-MFA-API kann:

Unterstützung der Benutzerregistrierung mit MFA-Faktoren, die vom Administrator aktiviert wurden
Erhöhen Sie die Sicherheit der kennwortbasierten Authentifizierung mit der Multifaktor-Authentifizierung (MFA), indem Sie eine zusätzliche Überprüfung benötigen, z. B. einen zeitbasierten Einmal-Passcode oder einen SMS-Passcode.
Führen Sie die MFA-Registrierung, die MFA-Verifizierung und die Verwaltung von Benutzerauthentifizierungsfaktoren durch.

In diesem Anwendungsfall sind die folgenden Beispielsets enthalten:

Faktoranmeldung mit Verifizierung

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

In den folgenden Anwendungsfällen werden die Schritte zum Registrieren verschiedener MFA-Faktoren mit der REST-API beschrieben:

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 Multifaktor-Authentifizierung konfigurieren aktiviert werden.

Laden Sie die Anwendungsbeispiele für die Identitätsdomainauthentifizierung 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 mit der userGUID oder der 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 bis userGUID abrufen

Dieser Schritt ruft die registrierten Faktoren für einen Benutzer basierend auf dem userGUID- oder Benutzernamen ab.

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 abrufen, indem Sie entweder "Benutzername" oder "Benutzer-GUID" verwenden. Die folgenden userIdType-Werte werden akzeptiert:

USER_GUID- Beispiel: userId muss USER_GUID enthalten, wie "7b3d902ab05b4214"
USER_NAME- Beispiel: Hier sollte userId USER_NAME enthalten, wie z.B. John.

Anforderungsbeispiel zum Abrufen der angemeldeten Faktoren basierend auf Benutzername

Das folgende Beispiel zeigt das Anforderungsbeispiel zum Abrufen der registrierten Faktoren für einen Benutzer basierend auf seinem 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 angemeldeten Faktoren basierend auf Benutzer-GUID

Das folgende Beispiel zeigt das Anforderungsbeispiel zum Abrufen der registrierten Faktoren für einen Benutzer basierend auf seiner 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 Schritt-für-Schritt-Beispiel für die Verwendung der Factor Enrollment API der Identitätsdomains, um sich für die Multifaktor-Authentifizierung (MFA) mit Faktorverifizierung anzumelden.

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

Laden Sie die Anwendungsbeispiele für die Identitätsdomainauthentifizierung 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: Überprüfung des bevorzugten Faktors initiieren

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

USER_GUID: Beispiel: userId muss USER_GUID enthalten, wie "7b3d902ab05b4214"
USER_NAME: Beispiel: Hier sollte userId USER_NAME enthalten, wie z.B. John.

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 wird. Nehmen Sie die requestId in jeden nachfolgenden Aufruf auf, um die Faktorprüfung 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 (im Falle von 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 otpCode in einer PATCH-Anforderung an {{HOST}}/mfa/v1/requests/{{requestId}} übergeben wird.

Der Client muss die folgenden Attribute enthalten:

otpCode: der vom Benutzer auf seinem Gerät empfangene Code
requestState: in der Schritt-1-Antwort empfangen
requestId: in der Schritt-1-Antwort 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, dass die Prüfung 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 Multifaktor-Authentifizierung konfigurieren aktiviert werden.

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 sowohl factorId als auch method in der Anforderung angeben. Wenn Sie die Verifizierungsfaktor-API verwenden müssen, ohne die userGUID anzugeben, können Sie eine eindeutige Benutzer-ID angeben, wie z.B. den Benutzernamen userId. Die userIdType in der Anforderung gibt an, welchen Typ von Zugangsdaten der Benutzer als Wert für userId übergibt. Die folgenden userIdType-Werte werden akzeptiert:

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

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

Eine Liste der registrierten Faktoren und deren IDs für einen Benutzer finden Sie im Anwendungsfall Registrierte Faktoren eines Benutzers abrufen. In diesem Beispiel ist der Backupfaktor "Sicherheitsfragen".

Beispiel für die Initiierung von Sicherheitsfragen zum Backupfaktor

Das folgende Beispiel zeigt den Inhalt der POST-Anforderung an den Endpunkt {{HOST}}/mfa/v1/requests/ 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 wird. Nehmen Sie die requestId in jeden nachfolgenden Aufruf auf, um die Faktorprüfung 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 wird. Nehmen Sie die requestId in jeden nachfolgenden Aufruf auf, um die Faktorprüfung 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 Backup-Faktor

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: vom Benutzer während 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"}

Erfolg bedeutet, dass die Prüfung erfolgreich war.

Schritt 2: Backupfaktor EMAIL initiieren und prüfen

Dieser Schritt initiiert die Verifizierung eines Backupfaktors EMAIL.

Beispiel zur Initiierung des EMAIL-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 zur Prüfung des EMAIL-Faktors:

{"status":"success"}

Erfolg bedeutet, dass die Prüfung erfolgreich war.

OTP-Faktoren zurückgeben, ohne den Benutzer zu benachrichtigen

Dieser Anwendungsfall enthält ein Beispiel dafür, wie die On Demand MFA-API initiiert wird, um einmalige 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 Multifaktor-Authentifizierungseinstellungen konfigurieren aktiviert werden.

Anforderungs-Payload


Attribut	Unterstützte Werte/Beispielwerte	Mehrwertig	Belegungs-Details
`userFlowControlledByExternalClient`	true / false	falsch	Diese Option festlegen auf `true` und der OTP wird in der Antwort in dem angegebenen verschlüsselten Format zurückgegeben. Hinweis: Das zur 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, um die OTP-Daten zu verschlüsseln. 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	Belegungs-Details
`otp`	Karte `"otp": { "value": "IMCw==", "alg": "RSAES-OAEP", "x5t": "<certificate thumbprint>" }`	falsch	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 zur 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 Multifaktor-Authentifizierung konfigurieren aktiviert werden.

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 starten

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

method: Definiert die Anmeldung für den 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, zeigt dieses Beispiel, wie ein erneutes Senden eines OTP angefordert wird. Der Client muss die folgenden Attribute enthalten:

requestState: in der Schritt-1-Antwort empfangen

resendOtp: Boolescher Wert, der angibt, dass der 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
factorId: Eindeutige ID, die für den registrierten Faktor generiert wird

Erfolg bedeutet:

Die angegebene userGUID ist gültig
Der Benutzer ist aktiv
Der 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: der vom Benutzer auf seinem Gerät empfangene Code
requestState: in der Schritt-1-Antwort 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
Der Benutzeraccount ist nicht gesperrt
Der SMS-Faktor ist aktiviert, und der Faktor wurde erfolgreich registriert

Beispiele für Fehlerantworten

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

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

Im folgenden Beispiel wird die Fehlermeldung im JSON-Format angezeigt, wenn der Benutzer gesperrt ist. Sie erhalten einen HTTP-Antwortcode 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 Multifaktor-Authentifizierung konfigurieren aktiviert werden.

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 starten

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

method: Definiert die Anmeldung bei E-Mail. Benutzer gibt die E-Mail-ID nicht weiter. Die primäre E-Mail-ID wird automatisch aus dem Benutzerprofil 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 Anmeldung 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 {{HOST}}/mfa/v1/users/{{userGUID}}/factors/{{factorID}}-Endpunkt im JSON-Format.

Wenn der Benutzer das OTP nicht erhält, zeigt dieses Beispiel, wie ein erneutes Senden eines OTP angefordert wird. Der Client muss die folgenden Attribute enthalten:

requestState: in der Schritt-1-Antwort empfangen
resendOtp:, um anzugeben, dass der 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: Diese muss vom Client im nächsten Schritt übergeben werden
displayName: E-Mail-ID aus Benutzerprofil abgerufen
method: Liste der Methoden, die für die EMAIL-Methode registriert werden
factorId: Eindeutige ID, die für den angemeldeten Faktor generiert wird

Erfolg bedeutet:

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

Schritt 2: E-MAIL-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: der Code, den der Benutzer mit seiner E-Mail-ID erhalten hat
requestState: in der Schritt-1-Antwort 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
Der Benutzeraccount ist nicht gesperrt
Der EMAIL-Faktor ist aktiviert, und der Faktor wurde erfolgreich registriert

Beispiele für Fehlerantworten

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

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

Im folgenden Beispiel wird die Fehlermeldung im JSON-Format angezeigt, wenn EMAIL deaktiviert ist. Sie erhalten einen HTTP-Antwortcode 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 bis userGUID abrufen

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

Bevorzugten Faktor initiieren und prüfen

Step1: Überprüfung 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 initiieren und prüfen

OTP-Faktoren zurückgeben, ohne den Benutzer zu benachrichtigen

Authentifizierungsfaktoranmeldung mit Faktorverifizierung - SMS

Schritt 1: SMS-Faktoranmeldung starten

Schritt 1a: OTP erneut senden

Schritt 2: SMS-Faktor aktivieren

Authentifizierungsfaktoranmeldung mit Faktorprüfung - E-Mail

Schritt 1: E-Mail-Faktoranmeldung starten

Schritt 1a: OTP erneut senden

Schritt 2: E-MAIL-Faktor aktivieren