Uso de la API de autenticación para desarrollar una página de conexión personalizada
Este caso de uso proporciona un ejemplo detallado del uso de la API de REST de los dominios de identidad para desarrollar una página de conexión personalizada para un dominio de identidad.
Utilice esta API de autenticación solo si va a crear su propia experiencia de conexión integral mediante el desarrollo de una aplicación de conexión personalizada que utilizarán los dominios de identidad.
Esta API de autenticación no se puede utilizar para integrar las aplicaciones con los dominios de identidad con fines de conexión única.
La API de autenticación se basa en el concepto de una máquina de estado. Las respuestas de solicitud informan a un cliente de aplicación lo que debe hacerse a continuación en lugar de exigir a los usuarios que tengan habilitadas las cookies de terceros en sus navegadores. Las cookies de terceros activadas en los navegadores pueden plantear problemas, especialmente para las aplicaciones B2C donde no se pueden aplicar controles sobre el comportamiento del usuario final. El requestState
proporcionado en cada respuesta de solicitud se utiliza en la siguiente solicitud, proporcionando al cliente la información que necesita para procesar la solicitud y, a continuación, proporcionar el siguiente juego de operaciones permitido.
- Ayude a verificar las credenciales de nombre de usuario y contraseña de un usuario como autenticación principal.
- Permite admitir la inscripción de usuarios con factores de MFA activados por el administrador.
- Refuerce la seguridad de la autenticación basada en contraseñas mediante la autenticación multifactor (MFA) al requerir una verificación adicional, como el uso de un código de acceso de un solo uso basado en tiempo o un código de acceso SMS.
- Permitir a los usuarios seleccionar un SAML externo o un proveedor de identidad social para la autenticación.
Consulte la recopilación Postman de API de autenticación de dominios de identidad para obtener ejemplos completos de casos de uso de autenticación. Descargue la recopilación y el archivo de variables globales de la carpeta idcs-authn-api-rest-clients en GitHub y, a continuación, impórtelos en Postman.
- Autenticación de un proveedor de identidad SAML externo
- Autenticación de un proveedor de identidad SAML social
- Autenticación con un proveedor de identidad SAML externo y MFA
- Autenticación con Nombre de Usuario y Contraseña
- Autenticación de nombre de usuario y contraseña con consentimiento de discriminación horaria
- Generación de token de acceso mediante la API de autenticación
- Autenticación de nombre de usuario y contraseña e inscripción en la recuperación de cuentas
- Autenticación de Nombre de Usuario y Contraseña e Inscripción en Recuperación de Cuentas y MFA
- Autenticación con nombre de usuario y contraseña e inscripción en MFA
- Autenticación con Nombre de Usuario, Contraseña y MFA
Autenticación y códigos de estado de API de MFA a demanda
Autenticación con un proveedor de identidad SAML externo
En este caso de uso se tratan los pasos para utilizar dominios de identidad para autenticarse mediante un proveedor de identidad SAML externo (IdP).
- Utilice esta API de autenticación solo si va a crear su propia experiencia de conexión integral mediante el desarrollo de una aplicación de conexión personalizada para que la utilicen los dominios de identidad.
- Esta API de autenticación no se puede utilizar para integrar sus aplicaciones con dominios de identidad con fines de conexión única.
Descargue la recopilación de ejemplos de casos de uso de autenticación de dominios de identidad y el archivo de variables globales de la carpeta idcs-authn-api-rest-clients en el repositorio idm-samples GitHub y, a continuación, impórtelos en Postman.
Paso 1: Inicio del flujo de autenticación
Un usuario abre una ventana del explorador para acceder a una página protegida.
/authorize
. Esto inicia el proceso de autenticación. En lugar de presentar la página de conexión por defecto, los dominios de identidad responden creando y enviando un formulario HTML que contiene los parámetros loginCtx
y signature
al explorador.Debe exponer un punto final para recibir la publicación del formulario y leer los dos valores de parámetros.
Ejemplo de formulario HTML POST
A continuación se muestra un ejemplo de formulario HTML POST que los dominios de identidad devuelven para llamar a la página de conexión personalizada:
<form name="autosubmit" id="autosubmit" action="<custom_ui_signin_URL>" method="POST" onload="submitform();">
<input name="loginCtx" value="<obfuscated_loginctx_value>" />
<input name="signature" value="signature_data" />
</form>
loginCtx
está cifrado con based64, la aplicación de conexión personalizada debe descifrar loginCtx
haciendo lo siguiente:- Decodificar mediante un descodificador base64 para obtener los datos binarios cifrados
- Utilizar el nombre del inquilino y generar una clave para el descifrado
- Descifrar los datos mediante la clave y los datos binarios
Ejemplo de lógica de descifrado para loginCtx cifrado en Java
A continuación, se muestra un ejemplo de lógica de descifrado:
public static String decrypt(String tenantName, String attrName, String attrDecryptValue ) {
String attrDecrypt = attrDecryptValue;
final String SHA_256_ALG = "SHA-256";
final String ENCRYPTION_ALG = "AES/CBC/PKCS5Padding";
final String SECRET_KEY_ALG = "AES";
String data = null;
MessageDigest md = null;
byte[] keyBytes = new byte[16];
try {
md = JCECryptoCache.getMessageDigestInstance(SHA_256_ALG);
byte[] digest = md.digest(tenantName.toLowerCase().getBytes("UTF-8"));
System.arraycopy(digest, 0, keyBytes, 0, 16);
} catch (Exception ex) {
ex.printStackTrace();
} finally {
JCECryptoCache.releaseMessageDigestInstance(md);
}
// encrypt the data
Cipher decipher = null;
try {
decipher = JCECryptoCache.getCipherInstance(ENCRYPTION_ALG);
SecretKey secretKey = new SecretKeySpec(keyBytes, SECRET_KEY_ALG);
decipher.init(Cipher.DECRYPT_MODE,
secretKey, new IvParameterSpec(new byte[16]));
byte[] decryptedData = decipher.doFinal(Base64.getDecoder().decode(attrDecrypt.getBytes("UTF-8")));
data = new String(decryptedData);
System.out.println("" + data);
} catch (Exception ex) {
ex.printStackTrace();
}
return data;
}
Ejemplo de respuesta
La respuesta debe ser similar a la del siguiente ejemplo:
{
"requestState": "TasNtIxDqWOfDKeTM",
"nextOp": [
"credSubmit",
"chooseIDP"
],
"nextAuthFactors": [
"IDP",
"USERNAME_PASSWORD"
],
"status": "success",
"ecId": "GmY95180000000000",
"USERNAME_PASSWORD": {
"credentials": [
"username",
"password"
]
},
"IDP": {
"configuredIDPs": [
{
"iconUrl": "null",
"idpName": "adc00peq",
"idpType": "Saml"
},
{
"idpId": "4bb89888feea4b00a0fab3a1a5627539",
"idpName": "Google",
"idpType": "Social"
}
],
"credentials": [
"idpId",
"idpType"
]
}
}
loginCtx
contiene algunos atributos importantes:- requestState: estado del proceso de autenticación. Debe utilizarse en futuras POST y GET para los puntos finales de la API de autenticación de dominios de identidad.
- nextOp: siguiente operación que debe realizar la aplicación de conexión personalizada.
- nextAuthFactors: los posibles factores de autenticación que debe presentar la página de conexión.
Los valores de estos atributos definen qué factor de autenticación, proveedores de identidad y proveedores sociales se presentan en la página de conexión. Aparece la página de conexión que contiene los valores descifrados del parámetro loginCtx
junto con el token de acceso. La página de conexión incluye JavaScript que se utiliza para realizar llamadas AJAX a dominios de identidad.
Paso 2: Seleccionar un proveedor de identidad SAML
/sso/v1/sdk/idp
. Para este paso, se deben incluir los siguientes atributos:requestState:
recibido en la respuesta del paso 1idpName:
nombre de IdP recibido en la respuesta del paso 1- Tipo
idpType:
de IdP recibido en la respuesta del paso 1 (en este ejemplo, es SAML) - ID
idpId:
de IdP recibido en la respuesta del paso 1 appName:
nombre de la aplicación a la que el cliente desea acceder- ID de cliente
clientID:
de la aplicación a la que intenta acceder el explorador - El parámetro
authorization:
es necesario para la Idp segura
Ejemplo de código POST de formulario HTML para seleccionar un SAML IdP
var addParamValues = function(myform, value, paramName) {
if (value !== null && value !== 'undefined') {
param = document.createElement("input");
param.value = value;
param.name = paramName;
myform.appendChild(param);
}
};
var chooseRemoteIDP = function(name, idpId, type) {
var myform = document.createElement("form");
myform.action = GlobalConfig.idcsBaseURL + "/sso/v1/sdk/secure/idp";
myform.method = "post";
<%
Credentials creds = CredentialsList.getCredentials().get(attr);
String clientId = creds.getId();
%>
var clientId = '<%=clientId%>';
addParamValues(myform, name, "idpName");
addParamValues(myform, type, "idpType");
addParamValues(myform, idpId, "idpId");
addParamValues(myform, clientId, "clientId");
addParamValues(myform, authorization, "accesstoken")
addParamValues(myform, GlobalConfig.requestState, "requestState");
document.body.appendChild(myform);
myform.submit();
};
var activateIdp = function(name, idpId) {
chooseRemoteIDP(name, idpId, "SAML");
};
var activateSocialIdp = function(name, idpId) {
chooseRemoteIDP(name, idpId, "SOCIAL");
};
Ejemplo de solicitud
A continuación, se muestra un ejemplo del contenido de la publicación de formularios en el punto final /sso/v1/sdk/secure/idp
:
requestState=value&idpName=value&idpType=SAML&idpId=value&appName=name&clientID=value&authorization=accesstoken
Ejemplo de respuesta
El siguiente ejemplo muestra el contenido de la respuesta en formato HTTP estándar:
HTTP/1.1 302 See Other
Date: Tue, 30 Oct 2018 04:40:05 GMT
Content-Length: 0
Connection: keep-alive
Pragma: no-cache
Location: https://<domainURL>/idp/sso (Example URL)
Set-cookie: ORA_OCIS_REQ_1=+fxgW2P7bgQayiki5P;Version=1;Path=/;Secure;HttpOnly
Expires: Sat, 01 Jan 2000 00:00:00 GMT
X-xss-protection: 1; mode=block
X-content-type-options: nosniff
Los dominios de identidad procesan la solicitud y redirigen el explorador al IdP externo seleccionado para la autenticación y autorización. Cuando finaliza el IdP externo, el explorador se redirige a los dominios de identidad. Los dominios de identidad validan la respuesta de afirmación y comprueban si se necesita autenticación adicional, como MFA.
Si no se requiere autenticación adicional, los dominios de identidad crean la sesión y redirigen el explorador a la URL de destino. O bien, los dominios de identidad crean una publicación de formulario de envío automático HTML en la página de conexión personalizada que contiene authnToken
. A continuación, la página de conexión personalizada crea la sesión. Consulte Creación de Sesiones.
Autenticación con un Proveedor de Identidad Social
En este caso de uso se analizan los pasos para utilizar dominios de identidad para autenticarse mediante un proveedor de identidad social (IdP), como Facebook o Google.
- Utilice esta API de autenticación solo si va a crear su propia experiencia de conexión integral mediante el desarrollo de una aplicación de conexión personalizada para que la utilicen los dominios de identidad.
- Esta API de autenticación no se puede utilizar para integrar sus aplicaciones con dominios de identidad con fines de conexión única.
Descargue la recopilación de ejemplos de casos de uso de autenticación de dominios de identidad y el archivo de variables globales de la carpeta idcs-authn-api-rest-clients en el repositorio idm-samples GitHub y, a continuación, impórtelos en Postman.
Paso 1: Inicio del flujo de autenticación
Un usuario abre una ventana del explorador para acceder a una página protegida.
/authorize
. Esto inicia el proceso de autenticación. En lugar de presentar la página de conexión por defecto, los dominios de identidad responden creando y enviando un formulario HTML que contiene los parámetros loginCtx
y signature
al explorador.Debe exponer un punto final para recibir la publicación del formulario y leer los dos valores de parámetros.
Ejemplo de formulario HTML POST
A continuación se muestra un ejemplo de formulario HTML POST que los dominios de identidad devuelven para llamar a la página de conexión personalizada:
<form name="autosubmit" id="autosubmit" action="<custom_ui_signin_URL>" method="POST" onload="submitform();">
<input name="loginCtx" value="<obfuscated_loginctx_value>" />
<input name="signature" value="signature_data" />
</form>
loginCtx
está cifrado con based64, la aplicación de conexión personalizada debe descifrar loginCtx
haciendo lo siguiente:Ejemplo de lógica de descifrado para loginCtx cifrado en Java
A continuación, se muestra un ejemplo de lógica de descifrado:
public static String decrypt(String tenantName, String attrName, String attrDecryptValue ) {
String attrDecrypt = attrDecryptValue;
final String SHA_256_ALG = "SHA-256";
final String ENCRYPTION_ALG = "AES/CBC/PKCS5Padding";
final String SECRET_KEY_ALG = "AES";
String data = null;
MessageDigest md = null;
byte[] keyBytes = new byte[16];
try {
md = JCECryptoCache.getMessageDigestInstance(SHA_256_ALG);
byte[] digest = md.digest(tenantName.toLowerCase().getBytes("UTF-8"));
System.arraycopy(digest, 0, keyBytes, 0, 16);
} catch (Exception ex) {
ex.printStackTrace();
} finally {
JCECryptoCache.releaseMessageDigestInstance(md);
}
// encrypt the data
Cipher decipher = null;
try {
decipher = JCECryptoCache.getCipherInstance(ENCRYPTION_ALG);
SecretKey secretKey = new SecretKeySpec(keyBytes, SECRET_KEY_ALG);
decipher.init(Cipher.DECRYPT_MODE,
secretKey, new IvParameterSpec(new byte[16]));
byte[] decryptedData = decipher.doFinal(Base64.getDecoder().decode(attrDecrypt.getBytes("UTF-8")));
data = new String(decryptedData);
System.out.println("" + data);
} catch (Exception ex) {
ex.printStackTrace();
}
return data;
}
Ejemplo de respuesta
La respuesta debe ser similar a la del siguiente ejemplo:
{
"requestState": "TasNtIxDqWOfDKeTM",
"nextOp": [
"credSubmit",
"chooseIDP"
],
"nextAuthFactors": [
"IDP",
"USERNAME_PASSWORD"
],
"status": "success",
"ecId": "GmY95180000000000",
"USERNAME_PASSWORD": {
"credentials": [
"username",
"password"
]
},
"IDP": {
"configuredIDPs": [
{
"iconUrl": "null",
"idpName": "adc00peq",
"idpType": "Saml"
},
{
"idpId": "4bb89888feea4b00a0fab3a1a5627539",
"idpName": "Google",
"idpType": "Social"
}
],
"credentials": [
"idpId",
"idpType"
]
}
}
loginCtx
contiene algunos atributos importantes:Los valores de estos atributos definen qué factor de autenticación, proveedores de identidad y proveedores sociales se presentan en la página de conexión. Aparece la página de conexión que contiene los valores descifrados del parámetro loginCtx
junto con el token de acceso. La página de conexión incluye JavaScript que se utiliza para realizar llamadas AJAX a dominios de identidad.
Paso 2: Seleccionar Proveedor de Identidad Social
/sso/v1/sdk/idp
. Para este paso, se deben incluir los siguientes atributos:Ejemplo de código POST de formulario HTML para seleccionar un Social IdP
var addParamValues = function(myform, value, paramName) {
if (value !== null && value !== 'undefined') {
param = document.createElement("input");
param.value = value;
param.name = paramName;
myform.appendChild(param);
}
};
var chooseRemoteIDP = function(name, idpId, type) {
var myform = document.createElement("form");
myform.action = GlobalConfig.idcsBaseURL + "/sso/v1/sdk/secure/idp";
myform.method = "post";
<%
Credentials creds = CredentialsList.getCredentials().get(attr);
String clientId = creds.getId();
%>
var clientId = '<%=clientId%>';
addParamValues(myform, name, "idpName");
addParamValues(myform, type, "idpType");
addParamValues(myform, idpId, "idpId");
addParamValues(myform, clientId, "clientId");
addParamValues(myform, authorization, "accesstoken")
addParamValues(myform, GlobalConfig.requestState, "requestState");
document.body.appendChild(myform);
myform.submit();
};
var activateIdp = function(name, idpId) {
chooseRemoteIDP(name, idpId, "SAML");
};
var activateSocialIdp = function(name, idpId) {
chooseRemoteIDP(name, idpId, "SOCIAL");
};
Ejemplo de solicitud
A continuación, se muestra un ejemplo del contenido de la publicación de formularios en el punto final /sso/v1/sdk/secure/idp
:
requestState=value&idpName=value&idpType=Social&idpId=value&appName=name&clientID=value&authorization=accesstoken
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
HTTP/1.1 302 See Other
Date: Tue, 30 Oct 2018 04:40:05 GMT
Content-Length: 0
Connection: keep-alive
Pragma: no-cache
Location: https://<domainURL>/idp/sso (Example URL)
Set-cookie: ORA_OCIS_REQ_1=+fxgW2P7bgQayiki5P;Version=1;Path=/;Secure;HttpOnly
Expires: Sat, 01 Jan 2000 00:00:00 GMT
X-xss-protection: 1; mode=block
X-content-type-options: nosniff
Los dominios de identidad procesan la solicitud y redirigen el explorador al IdP social seleccionado para la autenticación y autorización. Cuando finaliza el IdP social, el explorador se redirige a los dominios de identidad. Los dominios de identidad validan la respuesta de afirmación y comprueban si se necesita autenticación adicional, como MFA.
Si no se requiere autenticación adicional, los dominios de identidad crean la sesión y redirigen el explorador a la URL de destino. O bien, los dominios de identidad crean una publicación de formulario de envío automático HTML en la página de conexión personalizada que contiene authnToken
. A continuación, la página de conexión personalizada crea la sesión. Consulte Creación de Sesiones.
Autenticación con un proveedor de identidad SAML externo y MFA
En este caso de uso se tratan los pasos para utilizar dominios de identidad para autenticarse mediante un proveedor de identidad SAML externo (IdP) y la autenticación multifactor (MFA).
- Utilice esta API de autenticación solo si va a crear su propia experiencia de conexión integral mediante el desarrollo de una aplicación de conexión personalizada para que la utilicen los dominios de identidad.
- Esta API de autenticación no se puede utilizar para integrar sus aplicaciones con dominios de identidad con fines de conexión única.
Descargue la recopilación de ejemplos de casos de uso de autenticación de dominios de identidad y el archivo de variables globales de la carpeta idcs-authn-api-rest-clients en el repositorio idm-samples GitHub y, a continuación, impórtelos en Postman.
Paso 1: Inicio del flujo de autenticación
Un usuario abre una ventana del explorador para acceder a una página protegida.
/authorize
. Esto inicia el proceso de autenticación. En lugar de presentar la página de conexión por defecto, los dominios de identidad responden creando y enviando un formulario HTML que contiene los parámetros loginCtx
y signature
al explorador.Debe exponer un punto final para recibir la publicación del formulario y leer los dos valores de parámetros.
Ejemplo de formulario HTML POST
A continuación se muestra un ejemplo de formulario HTML POST que los dominios de identidad devuelven para llamar a la página de conexión personalizada:
<form name="autosubmit" id="autosubmit" action="<custom_ui_signin_URL>" method="POST" onload="submitform();">
<input name="loginCtx" value="<obfuscated_loginctx_value>" />
<input name="signature" value="signature_data" />
</form>
loginCtx
está cifrado con based64, la aplicación de conexión personalizada debe descifrar loginCtx
haciendo lo siguiente:- Decodificar mediante un descodificador base64 para obtener los datos binarios cifrados
- Utilizar el nombre del inquilino y generar una clave para el descifrado
- Descifrar los datos mediante la clave y los datos binarios
Ejemplo de lógica de descifrado para loginCtx cifrado en Java
A continuación, se muestra un ejemplo de lógica de descifrado:
public static String decrypt(String tenantName, String attrName, String attrDecryptValue)
{
String attrDecrypt = attrDecryptValue;
final String SHA_256_ALG = "SHA-256";
final String ENCRYPTION_ALG = "AES/CBC/PKCS5Padding";
final String SECRET_KEY_ALG = "AES";
String data = null;
MessageDigest md = null;
byte[] keyBytes = new byte[16];
try {
md = MessageDigest.getInstance(SHA_256_ALG);
byte[] digest = md.digest(tenantName.toLowerCase().getBytes("UTF-8"));
System.arraycopy(digest, 0, keyBytes, 0, 16);
} catch (Exception ex)
{
ex.printStackTrace();
}
// encrypt the data
Cipher decipher = null;
try {
decipher = Cipher.getInstance(ENCRYPTION_ALG);
SecretKey secretKey = new SecretKeySpec(keyBytes, SECRET_KEY_ALG);
decipher.init(Cipher.DECRYPT_MODE,
secretKey, new IvParameterSpec(new byte[16]));
byte[] decryptedData = decipher.doFinal(Base64.getDecoder().decode(attrDecrypt.getBytes("UTF-8")));
data = new String(decryptedData);
System.out.println("" + data); }
catch (Exception ex)
{
ex.printStackTrace();
}
return data;
}
Ejemplo de respuesta
La respuesta debe ser similar a la del siguiente ejemplo:
{
"requestState": "TasNtIxDqWOfDKeTM",
"nextOp": [
"credSubmit",
"chooseIDP"
],
"nextAuthFactors": [
"IDP",
"USERNAME_PASSWORD"
],
"status": "success",
"ecId": "GmY95180000000000",
"USERNAME_PASSWORD": {
"credentials": [
"username",
"password"
]
},
"IDP": {
"configuredIDPs": [
{
"iconUrl": "null",
"idpName": "adc00peq",
"idpType": "Saml"
},
{
"idpId": "4bb89888feea4b00a0fab3a1a5627539",
"idpName": "Google",
"idpType": "Social"
}
],
"credentials": [
"idpId",
"idpType"
]
}
}
loginCtx
contiene algunos atributos importantes:- requestState: estado del proceso de autenticación. Debe utilizarse en futuras POST y GET para los puntos finales de la API de autenticación de dominios de identidad.
- nextOp: siguiente operación que debe realizar la aplicación de conexión personalizada.
- nextAuthFactors: los posibles factores de autenticación que debe presentar la página de conexión.
Los valores de estos atributos definen qué factor de autenticación, proveedores de identidad y proveedores sociales se presentan en la página de conexión. Aparece la página de conexión que contiene los valores descifrados del parámetro loginCtx
junto con el token de acceso. La página de conexión incluye JavaScript que se utiliza para realizar llamadas AJAX a dominios de identidad.
Paso 2: Seleccionar un proveedor de identidad externo
/sso/v1/sdk/idp
. Para este paso, se deben incluir los siguientes atributos:requestState:
recibido en la respuesta del paso 1idpName:
nombre de IdP recibido en la respuesta del paso 1- Tipo
idpType:
de IdP recibido en la respuesta del paso 1 (en este ejemplo, es SAML) - ID
idpId:
de IdP recibido en la respuesta del paso 1 appName:
nombre de la aplicación a la que el cliente desea acceder- ID de cliente
clientID:
de la aplicación a la que intenta acceder el explorador - El parámetro
authorization:
es necesario para la Idp segura
Ejemplo de código POST de formulario HTML para seleccionar un IdP externo
var addParamValues = function(myform, value, paramName) {
if (value !== null && value !== 'undefined') {
param = document.createElement("input");
param.value = value;
param.name = paramName;
myform.appendChild(param);
}
};
var chooseRemoteIDP = function(name, idpId, type) {
var myform = document.createElement("form");
myform.action = GlobalConfig.idcsBaseURL + "/sso/v1/sdk/secure/idp";
myform.method = "post";
<%
Credentials creds = CredentialsList.getCredentials().get(attr);
String clientId = creds.getId();
%>
var clientId = '<%=clientId%>';
addParamValues(myform, name, "idpName");
addParamValues(myform, type, "idpType");
addParamValues(myform, idpId, "idpId");
addParamValues(myform, clientId, "clientId");
addParamValues(myform, authorization, "accesstoken")
addParamValues(myform, GlobalConfig.requestState, "requestState");
document.body.appendChild(myform);
myform.submit();
};
var activateIdp = function(name, idpId) {
chooseRemoteIDP(name, idpId, "SAML");
};
var activateSocialIdp = function(name, idpId) {
chooseRemoteIDP(name, idpId, "SOCIAL");
};
Ejemplo de solicitud
A continuación, se muestra un ejemplo del contenido de la publicación de formularios en el punto final /sso/v1/sdk/secure/idp
:
requestState=value&idpName=value&idpType=SAML&idpId=value&appName=name&clientID=value&authorization=accesstoken
Ejemplo de respuesta
El siguiente ejemplo muestra el contenido de la respuesta en formato HTTP estándar:
HTTP/1.1 302 See Other
Date: Tue, 30 Oct 2018 04:40:05 GMT
Content-Length: 0
Connection: keep-alive
Pragma: no-cache
Location: https://<domainURL>/idp/sso (Example URL)
Set-cookie: ORA_OCIS_REQ_1=+fxgW2P7bgQayiki5P;Version=1;Path=/;Secure;HttpOnly
Expires: Sat, 01 Jan 2000 00:00:00 GMT
X-xss-protection: 1; mode=block
X-content-type-options: nosniff
Los dominios de identidad procesan la solicitud y redirigen el explorador al IdP externo seleccionado para la autenticación y autorización. Cuando finaliza el IdP externo, redirige el explorador a los dominios de identidad, que, a continuación, redirige el explorador para iniciar la verificación en 2 pasos.
Paso 3: Autenticación mediante el factor preferido (SMS)
Los pasos iniciales para iniciar la verificación en 2 pasos son similares al paso 1. Los dominios de identidad crean y envían un formulario HTML que contiene los parámetros loginCtx
y signature
cifrados. Consulte el paso 1 para obtener información detallada sobre el formulario POST y cómo descifrar.
Después de descifrar el parámetro loginCtx
, la respuesta debe ser similar al siguiente ejemplo:
{
"status": "success",
"displayName": "Joe's iPhone",
"nextAuthFactors": [
"SMS"
],
"SMS": {
"credentials": [
"otpCode"
]
},
"nextOp": [
"credSubmit",
"getBackupFactors",
"resendCode"
],
"requestState": "QjyV3ueFrGQCO.....84gQw2UUm2V7s",
"trustedDeviceSettings": {
"trustDurationInDays": 15
}
}
loginCtx
contiene algunos atributos importantes:- requestState: estado del proceso de autenticación. Debe utilizarse en futuras POST y GET para los puntos finales de la API de autenticación de dominios de identidad.
- nextOp: siguiente operación que debe realizar la aplicación de conexión personalizada.
- nextAuthFactors: los posibles factores de autenticación que debe presentar la página de conexión.
Los valores de estos atributos definen qué factor de autenticación (en este ejemplo es SMS) presentar en la página de conexión. El usuario introduce el código de acceso de un solo uso que recibe en su dispositivo.
op:
indica al servidor qué tipo de operación desea el clienteotpCode:
el código enviado al dispositivo del usuariorequestState:
recibido en la respuesta del paso 2
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST en formato JSON para completar la autenticación mediante el método preferido:
{
"op":"credSubmit",
"credentials":{
"otpCode":"108685"
},
"requestState":"{{requestState}}"
}
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"authnToken": "eyJraWQiOiJT.....kLbxxL97U_0Q",
"status": "success"
}
A continuación, se debe crear una sesión. Una vez creada la sesión, el explorador se redirige a la URL solicitada originalmente. Consulte Creación de Sesiones.
Creación de Sesiones
Este caso de uso proporciona un ejemplo de uso de dominios de identidad para crear una sesión después de la autenticación, por ejemplo, después de la autenticación mediante MFA.
Utilice esta API de autenticación solo si va a crear su propia experiencia de conexión integral mediante el desarrollo de una aplicación de conexión personalizada que utilizarán los dominios de identidad.
Esta API de autenticación no se puede utilizar para integrar las aplicaciones con los dominios de identidad con fines de conexión única.
Consulte los otros casos de uso de Uso de la API de autenticación para obtener información sobre el uso de la API de autenticación.
Envíe authnToken
y requestState
como FORM POST cuando el cliente haya terminado con la autenticación y la MFA, y necesite crear una sesión. Para este paso, createSession
debe aparecer como valor de atributo nextOp
en la última respuesta recibida y FORM POST debe incluir uno de los siguientes atributos.
/sso/v1/sdk/secure/session
:requestState:
recibido en la última respuestaO
authnToken:
recibido en la última respuestaAND (y)
- El parámetro
authorization:
es necesario para la sesión segura
Ejemplo de solicitud
A continuación, se muestra un ejemplo del contenido de la publicación de formularios en el punto final /sso/v1/sdk/secure/session
:
requestState=value&authorization=<client sign-in access token>
authnToken=<value received from a previous response>&authorization=<client sign-in access token>
Ejemplo de respuesta
El siguiente ejemplo muestra el contenido de la respuesta en formato HTTP estándar:
HTTP/1.1 302 See Other
Date: Tue, 30 Oct 2018 04:40:05 GMT
Content-Length: 0
Connection: keep-alive
Pragma: no-cache
Location: https://<domainURL>/idp/sso (Example URL)
Set-cookie: ORA_OCIS_REQ_1=+fxgW2P7bgQayiki5P;Version=1;Path=/;Secure;HttpOnly
Expires: Sat, 01 Jan 2000 00:00:00 GMT
X-xss-protection: 1; mode=block
X-content-type-options: nosniff
Si createSession
no aparece como valor para el parámetro nextOp
en la última respuesta recibida, puede que tenga que crear un token antes de crear una sesión. Si createSession
se muestra como un valor para nextOp
, se puede llamar al punto final sdk/session
directamente utilizando solo requestState
.
Ejemplo de solicitud
En el siguiente ejemplo se muestra la solicitud de token al punto final /sso/v1/sdk/authenticate
en formato JSON:
{
"op":"createToken",
"requestState":"{{requestState}}"
}
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"authnToken":"eyJraWQiOiJ....4IacnWKSQ",
"status":"success"
}
El servidor comprueba que no sea necesaria ninguna otra evaluación de factores. Si no se requiere ninguna otra evaluación, el token se envía en la respuesta.
Autenticación con Nombre de Usuario y Contraseña
Este caso de uso proporciona un ejemplo paso a paso del uso de la API de autenticación de dominios de identidad para autenticarse con las credenciales de un usuario.
- Utilice esta API de autenticación solo si va a crear su propia experiencia de conexión integral mediante el desarrollo de una aplicación de conexión personalizada para que la utilicen los dominios de identidad.
- Esta API de autenticación no se puede utilizar para integrar sus aplicaciones con dominios de identidad con fines de conexión única.
Descargue la recopilación de ejemplos de casos de uso de autenticación de dominios de identidad y el archivo de variables globales de la carpeta idcs-authn-api-rest-clients en el repositorio idm-samples GitHub y, a continuación, impórtelos en Postman.
Use los siguientes pasos para el caso de uso.
Paso 1: Inicio del flujo de autenticación
Obtenga el requestState
inicial para iniciar el flujo de autenticación.
Ejemplo de solicitud
En el siguiente ejemplo se muestra la solicitud con formato cURL:
curl -X GET
-H "Content-Type: application/json"
-H "Authorization: Bearer {{access_token_value}}"
https://<domainURL>/sso/v1/sdk/authenticate?appName={{app_name}}
appName
es opcional. appName
es el nombre de la aplicación a la que el cliente desea acceder. Si se proporciona appName
, se procesan las políticas de conexión específicas de la aplicación y se desafía al cliente por los factores necesarios en función de esa política.Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"status": "success",
"ecId": "ecId",
"nextOp": [
"credSubmit"
],
"nextAuthFactors": [
"USERNAME_PASSWORD"
],
"USERNAME_PASSWORD": {
"credentials": [
"username",
"example-password"
]
},
"requestState": "{{requestState}}"
}
En la respuesta, el valor nextOp
indica lo que se puede enviar como valor op
en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit
se debe enviar en el siguiente paso. requestState
contiene datos contextuales necesarios para procesar la solicitud.
Paso 2: Enviar las credenciales del usuario
Envíe las credenciales del usuario como primer factor, que son el nombre de usuario y la contraseña. Para este paso, el cliente debe incluir los siguientes atributos:
-
credentials:
nombre de usuario y contraseña -
requestState:
recibido en la respuesta del paso 1 -
op:
indica al servidor qué tipo de operación desea el cliente
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:
{
"op": "credSubmit",
"credentials": {
"username": "{{username}}",
"password": "{{password}}"
},
"requestState": "{{requestState}}"
}
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"authnToken": "eyJraWQiOiJT.....UKofudtemmJE",
"status": "success"
}
Ejemplo de Respuesta de Error
En el siguiente ejemplo se muestra el contenido de la respuesta en formato JSON cuando el nombre de usuario o la contraseña proporcionados no son válidos:
{
"status": "failed",
"cause": [
{
"message": "You entered an incorrect username or password.",
"code": "AUTH-3001"
}
],
"requestState": "e5kwGYx57taQ.....jyg3nEDFya"
}
Autenticación de nombre de usuario y contraseña con consentimiento de discriminación horaria
Este caso de uso proporciona un ejemplo paso a paso del uso de la API de autenticación de dominios de identidad para autenticarse con las credenciales de un usuario con el consentimiento de TOU. Cuando el usuario acepta el consentimiento, se redirige al usuario a esa página de aplicación.
- Utilice esta API de autenticación solo si va a crear su propia experiencia de conexión integral mediante el desarrollo de una aplicación de conexión personalizada para que la utilicen los dominios de identidad.
- Esta API de autenticación no se puede utilizar para integrar sus aplicaciones con dominios de identidad con fines de conexión única.
Descargue la recopilación de ejemplos de casos de uso de autenticación de dominios de identidad y el archivo de variables globales de la carpeta idcs-authn-api-rest-clients en el repositorio idm-samples GitHub y, a continuación, impórtelos en Postman.
Paso 1: Inicio del flujo de autenticación
Obtenga el requestState
inicial para iniciar el flujo de autenticación.
Ejemplo de solicitud
En el siguiente ejemplo se muestra la solicitud con formato cURL:
curl -X GET
-H "Content-Type: application/json"
-H "Authorization: Bearer {{access_token_value}}"
https://<domainURL>/sso/v1/sdk/authenticate?appName={{app_name}}
appName
es opcional. appName
es el nombre de la aplicación a la que el cliente desea acceder. Si se proporciona appName
, se procesan las políticas de conexión específicas de la aplicación y se desafía al cliente por los factores necesarios en función de esa política.Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"status": "success",
"ecId": "ecId",
"nextOp": [
"credSubmit"
],
"nextAuthFactors": [
"USERNAME_PASSWORD"
],
"USERNAME_PASSWORD": {
"credentials": [
"username",
"example-password"
]
},
"requestState": "{{requestState}}"
}
En la respuesta, el valor nextOp
indica lo que se puede enviar como valor op
en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit
se debe enviar en el siguiente paso. requestState
contiene datos contextuales necesarios para procesar la solicitud.
Paso 2: Enviar las credenciales del usuario sin MFA)
credentials:
nombre de usuario y contraseñarequestState:
recibido en la respuesta del paso 1op:
indica al servidor qué tipo de operación desea el cliente
Si el nombre de usuario y las contraseñas son válidos, el servidor responde con la sentencia TOU en la configuración regional especificada en el perfil del usuario. El servidor también solicita al usuario que proporcione su credencial de consentimiento en la siguiente solicitud. Si la sentencia TOU no está presente en la configuración regional del usuario fr
, se muestra la respuesta 401 con el mensaje de error AUTH-3036: Terms of Use Statement for locale fr not added.
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST en formato JSON para el punto final /sso/v1/sdk/authenticate
:
{
"op":"credSubmit",
"credentials":{
"username":"{{username}}",
"password":"{{password}}"
},
"requestState":"{{requestState}}"
}
}
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta en formato JSON cuando se agrega la configuración regional del usuario:
{
"nextOp": [
"acceptTOU"
],
"TOU": {
"statement": "This is a placeholder text. Customers must provide the actual Terms of Use.",
"credentials": [
"consent"
],
"locale": "en"
},
"requestState": "q/tRS4BFAdaimSBhq"
}
}
Ejemplo de Respuesta de Error
En el siguiente ejemplo se muestra el contenido de la respuesta en formato JSON cuando no se agrega el TOU para la configuración regional del usuario:
{
"status": "failed",
"ecId": "Q0ApB1Y1000000000",
"cause": [
{
"message": "Terms of Use Statement for locale fr isn't added.",
"code": "AUTH-3036"
}
]
}
}
Paso 3: Proporcionar el consentimiento de discriminación horaria
En este caso, el usuario acepta o rechaza las condiciones de uso de la aplicación. Si el usuario acepta las Condiciones de uso, se le redirige a la página de la aplicación.
Si el usuario rechaza las condiciones de uso, se muestra la respuesta 401 con el mensaje de error AUTH-3035: Debe aceptar las condiciones de uso para acceder a esta aplicación.
Ejemplo de solicitud
El siguiente ejemplo muestra el contenido de la solicitud en formato JSON cuando el usuario acepta TOU.
{
"op": "acceptTOU",
"credentials": {
"consent": true
},
"requestState": "{{requestState}}"
}
Ejemplo de solicitud
El siguiente ejemplo muestra el contenido de la solicitud en formato JSON cuando el usuario rechaza el TOU.
{
"op": "acceptTOU",
"credentials": {
"consent": false
},
"requestState": "{{requestState}}"
}
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta en formato JSON cuando el usuario acepta la sentencia TOU.
{
"authnToken": "eyJ4NXQjUzI1NiI6Iks0R0hvZVdoUm...YUAvuEOrERXrQRnjybdOkA2Q",
"status": "success",
"ecId": "Q0ApB1Y1000000000"
}
Ejemplo de Respuesta de Error
A continuación se muestra el contenido de la respuesta en formato JSON cuando el usuario rechaza la discriminación horaria.
{
"status": "failed",
"ecId": "Q0ApB1Y1000000000",
"cause": [
{
"message": "You must accept the Terms of Use to access this application.",
"code": "AUTH-3035"
}
]
}
Autenticación con Nombre de Usuario y Contraseña y MFA y Devolución de una OTP
Este caso de uso proporciona un ejemplo paso a paso del uso de la API de REST de dominios de identidad para autenticarse con las credenciales de un usuario y la autenticación multifactor (MFA) y para devolver una OTP cifrada en la respuesta.
Utilice esta API de autenticación solo si va a crear su propia experiencia de conexión integral mediante el desarrollo de una aplicación de conexión personalizada para que la utilicen los dominios de identidad. Esta API de autenticación no se puede utilizar para integrar sus aplicaciones con dominios de identidad con fines de conexión única.
Descargue la recopilación de ejemplos de casos de uso de autenticación de dominios de identidad y el archivo de variables globales de la carpeta idcs-authn-api-rest-clients en el repositorio idm-samples GitHub y, a continuación, impórtelos en Postman.
Los dominios de identidad se pueden configurar para enviar un código de acceso de un solo uso (OTP) basado en tiempo directamente a un usuario para la autenticación o para que el código de acceso se cifre y se envíe al cliente consumidor, que podrá enviarlo al usuario para la autenticación.
Por ejemplo, los administradores pueden configurar dominios de identidad para enviar códigos de contraseña de un solo uso (OTP) basados en tiempo a la aplicación Oracle Mobile Authenticator (OMA) o enviar por correo electrónico las OTP a la dirección de correo electrónico principal del usuario. En ambos casos, los dominios de identidad generan la OTP, la envían directamente al usuario y el usuario introduce el código para la autenticación. Para comprender cómo definir estas opciones mediante REST, consulte Inscripción de factor de autenticación con verificación de factor - SMS y Inscripción de factor de autenticación con verificación de factor - Correo electrónico.
-
Paso 1: Crear una aplicación CustomUI
-
Paso 2: Generar un par de claves para un certificado autofirmado
-
Paso 3: Configuración de la aplicación para devolver la OTP en la respuesta
-
Paso 4: Solicitar la OTP
En estos pasos se asume que la MFA está activada y que se crea una política de conexión para la MFA. Consulte Configuring Multifactor Authentication Settings.
Cifrado y descifrado
Esta implantación utiliza la siguiente especificación para cifrar y descifrar el código OTP recibido. Consulte PKCS #1: RSA Cryptography Specifications, Version 2.0, sección 7.1 RSAES-OAEP.
Código de descifrado de OTP
/*
* To change this license header, choose License Headers in Project Properties.
* To change this template file, choose Tools | Templates
* and open the template in the editor.
*/
package decryption;
import java.security.Key;
import java.security.KeyFactory;
import java.security.PrivateKey;
import java.security.cert.CertificateFactory;
import java.security.spec.PKCS8EncodedKeySpec;
import java.util.Base64;
import javax.crypto.Cipher;
/**
*
* @author <author>
*/
public class DecryptOtpCode {
private static Key getPrivateKey(String privateKeyPEM) throws Exception {
byte[] encoded = Base64.getDecoder().decode(privateKeyPEM);
KeyFactory kf = KeyFactory.getInstance("RSA");
PKCS8EncodedKeySpec keySpec = new PKCS8EncodedKeySpec(encoded);
return kf.generatePrivate(keySpec);
}
public static void main(String args[]) {
String value = "<encrypted_value>";
String privatekey =
"<pem_privatekey_data>";
try {
Cipher cipherInstance =
Cipher.getInstance("RSA/ECB/OAEPwithSHA1andMGF1Padding");
CertificateFactory factory = CertificateFactory.getInstance("X.509");
byte [] decoded = Base64.getDecoder().decode(value);
PrivateKey pKey = (PrivateKey)getPrivateKey(privatekey);
cipherInstance.init(Cipher.DECRYPT_MODE, pKey);
byte[] decrypted = cipherInstance.doFinal(decoded);
System.out.println("Decrypted text is " + new String(decrypted));
} catch (Exception e) {
//Unable to encrypt the content. Default to send the otp to user
//no error or exception thrown.
e.printStackTrace();
}
}
}
Paso 1: Crear una aplicación CustomUI
Consulte Agregar aplicaciones para obtener más información sobre las aplicaciones personalizadas.
Paso 2: Generar un par de claves para un certificado autofirmado
- Asegúrese de que el archivo de configuración
otp-client.conf
contenga la siguiente información. A continuación, genere un par de claves privada/pública.[ req ] encrypt_key = no default_bits = 2048 default_md = sha256 utf8 = yes string_mask = utf8only prompt = no distinguished_name = user_dn [ user_dn ] 0.organizationName = "Oracle" organizationalUnitName = "OCI" commonName = "OtpClient"
-
Utilice el siguiente comando para generar un certificado autofirmado.
#generate self signed client certificate openssl genrsa -out OtpClient.key 2048 openssl req -new -x509 -days 10000 -key OtpClient.key -out OtpClient.crt -subj "/CN=Root CA/C=IN/ST=KarnatakaCalifornia/L=Bangalore/O=Oracle" -config otp-client.conf openssl pkcs8 -topk8 -inform PEM -in OtpClient.key -out OtpClientX509Format.key -nocrypt
Paso 3: Configuración de la aplicación para devolver la OTP en la respuesta
- En la consola de Identity Cloud Service, amplíe Cajón de navegación, haga clic en Aplicaciones, Aplicación CustomUI, Configuración y, a continuación, en Configuración de cliente.
- Importar el certificado autofirmado en el certificado de cliente de confianza y Guardar la configuración.
Paso 4: Solicitar la OTP
Atributo | Valores soportados/valores de muestra | Con Varios Valores | Detalles de Uso |
---|---|---|---|
userFlowControlledByExternalClient
|
true / false | false |
Establecer esta opción en
y la OTP se devolverá en la respuesta en el formato cifrado especificado. Nota: El certificado utilizado para el cifrado se carga en la aplicación por adelantado y se hace referencia a él mediante el atributo |
x5t | Cadena / X509 Huella en miniatura del certificado SHA-1 |
Cuando se especifica, el servicio utiliza este certificado cargado para cifrar los datos de OTP. Nota: El atributo "x5t" debe coincidir con el certificado cargado. |
{
"op": "credSubmit",
"credentials": {
"username": "test.user",
"password": "example-password"
},
"userFlowControlledByExternalClient": true,
"x5t": "<certificate thumbprint>",
"requestState": "{{requestState}}"
}
Atributo | Valores soportados/valores de muestra | Con Varios Valores | Detalles de Uso |
---|---|---|---|
otp
|
Asignar
|
false |
Cuando está presente en la respuesta, el atributo contiene la OTP cifrada con los siguientes detalles.
|
Ejemplo de respuesta
{
"otp": {
"value": "IMsNO+rqNCw==",
"alg": "RSAES-OAEP",
"x5t": "<certificate thumbprint>"
},
"status": "success",
"ecId": "Ft^OD161000000000",
"displayName": "+91XXXXXXXX013",
"nextAuthFactors": [
"SMS"
],
"SMS": {
"credentials": [
"otpCode"
]
},
"nextOp": [
"credSubmit",
"getBackupFactors",
"resendCode"
],
"scenario": "AUTHENTICATION",
"requestState": "FrrACc",
"trustedDeviceSettings": {
"trustDurationInDays": 15
}
}
Generación de token de acceso mediante la API de autenticación
Este caso de uso proporciona un ejemplo paso a paso de cómo utilizar los dominios de identidad para generar un token de acceso mediante la API de autenticación. El usuario obtiene la información del usuario a través del token de acceso me mediante la API de autenticación.
- Utilice esta API de autenticación solo si va a crear su propia experiencia de conexión integral mediante el desarrollo de una aplicación de conexión personalizada para que la utilicen los dominios de identidad.
- Esta API de autenticación no se puede utilizar para integrar sus aplicaciones con dominios de identidad con fines de conexión única.
Descargue la recopilación de ejemplos de casos de uso de autenticación de dominios de identidad y el archivo de variables globales de la carpeta idcs-authn-api-rest-clients en el repositorio idm-samples GitHub y, a continuación, impórtelos en Postman.
Cuando el usuario intenta acceder a una aplicación asociada a TOU, el servidor de dominios de identidad utiliza el nombre de la aplicación para recuperar la política asignada a esta aplicación. Según la configuración del inquilino, el servidor obtiene el IDP y la política de autenticación y, a continuación, guía al usuario al siguiente paso.
Paso 1: Inicio del flujo de autenticación
Obtenga el requestState
inicial para iniciar el flujo de autenticación.
Ejemplo de solicitud
En el siguiente ejemplo se muestra la solicitud con formato cURL:
curl -X GET
-H "Content-Type: application/json"
-H "Authorization: Bearer {{access_token_value}}"
https://<domainURL>/sso/v1/sdk/authenticate?appName={{app_name}}
appName
es opcional. appName
es el nombre de la aplicación a la que el cliente desea acceder. Si se proporciona appName
, se procesan las políticas de conexión específicas de la aplicación y se desafía al cliente por los factores necesarios en función de esa política.Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"status": "success",
"ecId": "ecId",
"nextOp": [
"credSubmit"
],
"nextAuthFactors": [
"USERNAME_PASSWORD"
],
"USERNAME_PASSWORD": {
"credentials": [
"username",
"example-password"
]
},
"requestState": "{{requestState}}"
}
En la respuesta, el valor nextOp
indica lo que se puede enviar como valor op
en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit
se debe enviar en el siguiente paso. requestState
contiene datos contextuales necesarios para procesar la solicitud.
Paso 2: Enviar las credenciales del usuario
authnToken
. Se debe incluir lo siguiente en la solicitud:credentials:
nombre de usuario y contraseñarequestState:
recibido en la respuesta del paso 1op:
indica al servidor qué tipo de operación desea el cliente
AuthnToken
es el id_token en formato JWT que representa la información de usuario actual, la sesión y los datos de solicitud. Se utiliza para crear una cookie de sesión SSO y redirigir a la URL de destino. Si el nombre de usuario y la contraseña son válidos, se recupera AuthnToken
.
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST en formato JSON para el punto final /sso/v1/sdk/authenticate
:
{
"op":"credSubmit",
"credentials":{
"username":"admin@oracle.com",
"password":"example-password"
},
"requestState": "{{requestState}}"
}
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta en formato JSON donde se recupera AuthnToken
:
{
"authnToken": "eyJ4NXQjUzI1NiI6Iks0R0hvZ...ZLjOZmKAvORB8OaV1Xqt1GL3tx1kyWA",
"status": "success",
"ecId": "5fR1O171000000000"
}
Paso 3: Generar el token de acceso
Después de recuperar un AuthnToken
, se utiliza para obtener el token de acceso del servidor OAuth.
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud con formato JSON:
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&scope=urn:opc:idm:__myscopes__&assertion={{authnToken}}
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"access_token": "<redacted>",
"token_type": "Bearer",
"expires_in": 7600
}
Paso 4: Obtener información del usuario
El usuario envía el token de acceso para obtener su información, como nombre de usuario, nombre mostrado, ID de correo electrónico, etc.
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud con formato JSON.
{{HOST}}/admin/v1/Me
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON con información de usuario.
{
"idcsCreatedBy": {
"type": "App",
"display": "idcssm",
"value": "4ba14c4be74d48d497da6ce651209a06",
"$ref": "https://docteam.identity.internal.oracle.com:8943/admin/v1/Apps/4ba14c4be74d48d497da6ce651209a06"
},
"id": "de94e8399a0e4f23ac52fc681f5fb828",
"meta": {
"created": "2022-12-12T09:46:53.646Z",
"lastModified": "2022-12-13T10:35:32.604Z",
"resourceType": "Me",
"location": "https://docteam.identity.internal.oracle.com:8943/admin/v1/Me/de94e8399a0e4f23ac52fc681f5fb828"
},
"active": true,
"displayName": "admin opc",
"idcsLastModifiedBy": {
"value": "6567bac90beb4e65a2eb3b280b2f0d1f",
"display": "idcssso",
"type": "App",
"$ref": "https://docteam.identity.internal.oracle.com:8943/admin/v1/Apps/6567bac90beb4e65a2eb3b280b2f0d1f"
},
"nickName": "TAS_TENANT_ADMIN_USER",
"userName": "admin@oracle.com",
"urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User": {
"isFederatedUser": false
},
"emails": [
{
"verified": false,
"primary": false,
"secondary": false,
"value": "admin@oracle.com",
"type": "recovery"
},
{
"verified": false,
"primary": true,
"secondary": false,
"value": "admin@oracle.com",
"type": "work"
}
],
"urn:ietf:params:scim:schemas:oracle:idcs:extension:userState:User": {
"locked": {
"on": false
}
},
"name": {
"formatted": "admin opc",
"familyName": "opc",
"givenName": "admin"
},
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User",
"urn:ietf:params:scim:schemas:oracle:idcs:extension:userState:User"
]
}
Autenticación con Nombre de Usuario, Contraseña y MFA
Este caso de uso proporciona un ejemplo paso a paso del uso de la API de REST de dominios de identidad para autenticarse con las credenciales de un usuario y la autenticación multifactor (MFA).
- Utilice esta API de autenticación solo si va a crear su propia experiencia de conexión integral mediante el desarrollo de una aplicación de conexión personalizada para que la utilicen los dominios de identidad.
- Esta API de autenticación no se puede utilizar para integrar sus aplicaciones con dominios de identidad con fines de conexión única.
Descargue la recopilación de ejemplos de casos de uso de autenticación de dominios de identidad y el archivo de variables globales de la carpeta idcs-authn-api-rest-clients en el repositorio idm-samples GitHub y, a continuación, impórtelos en Postman.
Complete los siguientes pasos para este caso de uso:
En estos pasos se asume que la MFA está activada y que se crea una política de conexión para la MFA. Consulte Configuring Multifactor Authentication Settings.
Paso 1: Inicio del flujo de autenticación
Obtenga el requestState
inicial para iniciar el flujo de autenticación.
Ejemplo de solicitud
En el siguiente ejemplo se muestra la solicitud con formato cURL:
curl -X GET
-H "Content-Type: application/json"
-H "Authorization: Bearer {{access_token_value}}"
https://<domainURL>/sso/v1/sdk/authenticate?appName={{app_name}}
appName
es opcional. appName
es el nombre de la aplicación a la que el cliente desea acceder. Si se proporciona appName
, se procesan las políticas de conexión específicas de la aplicación y se desafía al cliente por los factores necesarios en función de esa política.Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"status": "success",
"ecId": "ecId",
"nextOp": [
"credSubmit"
],
"nextAuthFactors": [
"USERNAME_PASSWORD"
],
"USERNAME_PASSWORD": {
"credentials": [
"username",
"example-password"
]
},
"requestState": "{{requestState}}"
}
En la respuesta, el valor nextOp
indica lo que se puede enviar como valor op
en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit
se debe enviar en el siguiente paso. requestState
contiene datos contextuales necesarios para procesar la solicitud.
Paso 2: Enviar las credenciales del usuario
Envíe las credenciales del usuario como primer factor, que son el nombre de usuario y la contraseña. Para este paso, el cliente debe incluir los siguientes atributos:
-
credentials:
nombre de usuario y contraseña -
requestState:
recibido en la respuesta del paso 1 -
op:
indica al servidor qué tipo de operación desea el cliente
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:
{
"op": "credSubmit",
"credentials": {
"username": "{{username}}",
"password": "{{password}}"
},
"requestState": "{{requestState}}"
}
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta en formato JSON, ya que las notificaciones PUSH son el factor preferido:
{
"status": "pending",
"displayName": "Joe's iPhone",
"nextAuthFactors": [
"PUSH"
],
"cause": [
{
"code": "AUTH-1108",
"message": "Push Notification approval is pending."
}
],
"nextOp": [
"credSubmit",
"getBackupFactors"
],
"requestState": "rATagRibc//b.....xrKh7fJtIuWo",
"trustedDeviceSettings": {
"trustDurationInDays": 15
}
}
Si la configuración de dispositivo de confianza está desactivada en el nivel de inquilino, el atributo {{trustedDeviceSettings}}
no se devuelve en la respuesta.
{{trustedDeviceSettings}}
, pero el valor {{trustDurationInDays}}
se devuelve como 0
."trustedDeviceSettings": {
"trustDurationInDays": 0
}
En la respuesta, el estado es pending
, ya que el usuario debe permitir o denegar la notificación PUSH en su dispositivo. Los valores nextOp
de la respuesta indican lo que se puede enviar como valor op
en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit
se envía en el siguiente paso.
Paso 3: Autenticación mediante el factor preferido
Autenticar mediante el factor preferido, que en este ejemplo de caso de uso es Notificaciones PUSH. El cliente debe incluir los siguientes atributos en esta solicitud:
-
op:
indica al servidor qué tipo de operación desea el cliente -
requestState:
recibido en la respuesta del paso 2
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST en formato JSON para completar la autenticación mediante el método preferido:
{
"op":"credSubmit",
"requestState":"{{requestState}}"
}
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"authnToken": "eyJraWQiOiJT.....kLbxxL97U_0Q",
"status": "success"
}
Autenticación con nombre de usuario y contraseña e inscripción en MFA
Este caso de uso proporciona un ejemplo paso a paso del uso de la API de autenticación de dominios de identidad para autenticarse con las credenciales de un usuario y, a continuación, inscribirse en la autenticación multifactor (MFA).
- Utilice esta API de autenticación solo si va a crear su propia experiencia de conexión integral mediante el desarrollo de una aplicación de conexión personalizada para que la utilicen los dominios de identidad.
- Esta API de autenticación no se puede utilizar para integrar sus aplicaciones con dominios de identidad con fines de conexión única.
Descargue la recopilación de ejemplos de casos de uso de autenticación de dominios de identidad y el archivo de variables globales de la carpeta idcs-authn-api-rest-clients en el repositorio idm-samples GitHub y, a continuación, impórtelos en Postman.
En estos pasos se asume que la MFA está activada y que se crea una política de conexión para la MFA. Consulte Configuración de los ajustes de autenticación multifactor.
Paso 1: Inicio del flujo de autenticación
Obtenga el requestState
inicial para iniciar el flujo de autenticación.
Ejemplo de solicitud
En el siguiente ejemplo se muestra la solicitud con formato cURL:
curl -X GET
-H "Content-Type: application/json"
-H "Authorization: Bearer {{access_token_value}}"
https://<domainURL>/sso/v1/sdk/authenticate?appName={{app_name}}
appName
es opcional. appName
es el nombre de la aplicación a la que el cliente desea acceder. Si se proporciona appName
, se procesan las políticas de conexión específicas de la aplicación y se desafía al cliente por los factores necesarios en función de esa política.Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"status": "success",
"ecId": "ecId",
"nextOp": [
"credSubmit"
],
"nextAuthFactors": [
"USERNAME_PASSWORD"
],
"USERNAME_PASSWORD": {
"credentials": [
"username",
"example-password"
]
},
"requestState": "{{requestState}}"
}
En la respuesta, el valor nextOp
indica lo que se puede enviar como valor op
en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit
se debe enviar en el siguiente paso. requestState
contiene datos contextuales necesarios para procesar la solicitud.
Paso 2: Enviar las credenciales del usuario
Envíe las credenciales del usuario como primer factor, que son el nombre de usuario y la contraseña. Para este paso, el cliente debe incluir los siguientes atributos:
-
credentials:
nombre de usuario y contraseña -
requestState:
recibido en la respuesta del paso 1 -
op:
indica al servidor qué tipo de operación desea el cliente
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:
{
"op": "credSubmit",
"credentials": {
"username": "{{username}}",
"password": "{{password}}"
},
"requestState": "{{requestState}}"
}
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"status": "success",
"nextAuthFactors": [
"TOTP",
"SMS",
"EMAIL",
"SECURITY_QUESTIONS"
],
"TOTP": {
"credentials": [
"offlineTotp"
]
},
"SMS": {
"credentials": [
"phoneNumber"
]
},
"nextOp": [
"createToken",
"createSession",
"enrollment"
],
"mfaSettings": {
"enrollmentRequired": false
},
"requestState": "m3oIaGVOlHwA...../Fi+1RpmKmd4"
}
En este ejemplo de caso de uso, dado que la MFA se define como opcional en la política de conexión (indicada por el valor false
para el atributo enrollmentRequired
), al usuario se le da la opción de inscribirse u omitir la inscripción. Si se necesita MFA, el único valor nextOp
sería enrollment.
En este ejemplo de caso de uso, enrollment
se envía en el siguiente paso para iniciar la inscripción de factor de MFA para el usuario. Tenga en cuenta que BYPASSCODE falta como valor nextAuthFactors
, ya que el usuario no puede inscribirse mediante un código de bypass. El código de bypass debe ser generado por el usuario mediante Mi perfil o solicitando que un administrador genere uno para ellos.
Paso 3: Iniciar inscripción de autenticación de segundo factor
-
op:
indica al servidor qué tipo de operación desea el cliente -
authFactor:
define el factor de autenticación en el que el usuario desea inscribirse -
requestState:
recibido en la respuesta del paso 2
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:
{
"op":"enrollment",
"authFactor":"TOTP",
"requestState":"{{requestState}}"
}
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"status": "success",
"displayName": "Joe's Phone",
"TOTP": {
"credentials": [
"otpCode"
],
"qrCode": {
"content": "oraclemobileauthenticator://totp/user?issuer=example1&Period=30&algorithm=SHA1&digits=6&RSA=SHA256withRSA&Deviceid=22f38324e67f4e2bb8e9e24583924a31&RequestId=9b428c1a-abb3-40ee-bd24-5064a87b638e&LoginURL=https%3A%2F%2Fexampletenant.com%3A8943%2Fsso%2Fv1%2F&OTP=eyJraWQiOiJTSUdOSU5HX0tFWSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0.eyJkZXZpY2VfaWQiOiIyMmYzODMyNGU2N2Y0ZTJiYjhlOWUyNDU4MzkyNGEzMSIsImlzcyI6IkF1dGhTcnYiLCJleHAiOjE1MjcxODEwODEsImlhdCI6MTUyNzE4MDc4MSwidGVuYW50IjoidGVuYW50MSJ9.Of0Hv5H3aRpDqdsiFLO0YkK2gbzq78k3jaJFwoWwR5LKOEH-9qTt1zjSiXujPD1T__8fEZDi8iKDyxXtL5zjAlEKd5wI026JjekG58ROPjW8gADWcMrTGQ4Lgw4Q0UPjk8Fm8AloQ1vS6xpDre6S-Vv620z28EKWZK_yGhUVSfAJVzSUxaypLtQhOQJBCNAzCElUgqyav7Vpi2z5eVQBQRtXv-Z_sTgrFXaVmVU3uSNVcg6zVX2x0fMQFgeO5lyC3U2Yy9JgA7iMfAMpuNvBzW0GjyByPAYRVnHSLPuHL1qiNx9ygpoVEcFLQJcOPuDLW2bW9ZwbUcVdS0F4L_2NfA&ServiceType=TOTP&KeyPairLength=2048&SSE=Base32",
"imageType": "image/png",
"imageData": "iVBORw0KG.......5ErkJggg=="
}
},
"nextOp": [
"credSubmit",
"createToken",
"createSession",
"enrollment"
],
"mfaSettings": {
"enrollmentRequired": false
},
"requestState": "8A317/A1JiQe.....ce5/paoVOWw"
}
nextOp
indican lo que se puede enviar como valor op
en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit
se envía en el siguiente paso.El valor de
content
siempre empieza por oraclemobileauthenticator//.
Paso 4: Enviar credenciales de factor
requestState
que se recibieron en la respuesta del paso 3. Tenga en cuenta que la carga útil de solicitud no contiene el atributo authFactor
porque requestState
lo contiene. El cliente debe incluir los siguientes atributos:op:
indica al servidor qué tipo de operación desea el clienterequestState:
recibido en la respuesta del paso 3
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST en formato JSON para enviar las credenciales de factor:
{
"op":"credSubmit",
"requestState":"{{requestState}}"
}
Ejemplo de respuesta
El estado success
aparece en la respuesta cuando se completa la comunicación de canal secundario de la aplicación OMA al servidor y la verificación optCode
se realiza correctamente. En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"status": "success",
"displayName": "Joe's iPhone",
"nextOp": [
"createToken",
"createSession",
"enrollment"
],
"requestState": "eyZa+10USFR7.....6I2vnfK82hnQ"
}
En la respuesta, los valores nextOp
indican lo que se puede enviar como valor op
en la siguiente solicitud. En este ejemplo de caso de uso, createToken
se envía en el siguiente paso.
Ejemplo de respuesta pendiente
El estado pending
aparece cuando no se completa la comunicación de canal secundario de la aplicación de OMA al servidor. El cliente sigue sondeando cada 10 segundos y sigue sondeando durante dos minutos. Después de dos minutos, el servidor envía el estado de fallo si la verificación otpCode
no se realiza correctamente.
{
"status": "pending",
"cause": [
{
"code": "AUTH-1109",
"message": "Enrollment in the One-Time Passcode authentication method is pending verification."
}
],
"nextOp": [
"credSubmit",
"createToken",
"createSession",
"enrollment"
],
"mfaSettings": {
"enrollmentRequired": false
},
"requestState": "1bYZJeyi6bcp..........74RXYKmbdiZfVW8y7tNc"
}
Paso 5: Creación del token de autenticación
Este paso indica que el cliente ha terminado con todo authnFactors
y necesita una sesión creada. El servidor valida que no se necesita ninguna otra evaluación de factores (según lo definido para la política) y responde con el token o deniega el acceso. El cliente debe incluir los siguientes atributos:
-
op:
indica al servidor qué tipo de operación desea el cliente -
requestState:
recibido en la respuesta del paso 4
Ejemplo de solicitud
{
"op":"createToken",
"requestState":"{{requestState}}"
}
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"authnToken": "{{authnToken}}",
"status": "success"
}
Autenticación de nombre de usuario y contraseña e inscripción en la recuperación de cuentas
Este caso de uso proporciona un ejemplo paso a paso del uso de la API de autenticación de dominios de identidad para autenticarse con las credenciales de un usuario y, a continuación, inscribirse en la recuperación de cuenta.
- Utilice esta API de autenticación solo si va a crear su propia experiencia de conexión integral mediante el desarrollo de una aplicación de conexión personalizada para que la utilicen los dominios de identidad.
- Esta API de autenticación no se puede utilizar para integrar sus aplicaciones con dominios de identidad con fines de conexión única.
Descargue la recopilación de ejemplos de casos de uso de autenticación de dominios de identidad y el archivo de variables globales de la carpeta idcs-authn-api-rest-clients en el repositorio idm-samples GitHub y, a continuación, impórtelos en Postman.
En estos pasos se asume que hay varios factores activados para la recuperación de cuentas, pero la inscripción de MFA no está configurada. Consulte Configuración de la recuperación de cuenta y Configuración de los valores de autenticación multifactor.
Paso 1: Inicio del flujo de autenticación
Obtenga el requestState
inicial para iniciar el flujo de autenticación.
Ejemplo de solicitud
En el siguiente ejemplo se muestra la solicitud con formato cURL:
curl -X GET
-H "Content-Type: application/json"
-H "Authorization: Bearer {{access_token_value}}"
https://<domainURL>/sso/v1/sdk/authenticate?appName={{app_name}}
appName
es opcional. appName
es el nombre de la aplicación a la que el cliente desea acceder. Si se proporciona appName
, se procesan las políticas de conexión específicas de la aplicación y se desafía al cliente por los factores necesarios en función de esa política.Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"status": "success",
"ecId": "ecId",
"nextOp": [
"credSubmit"
],
"nextAuthFactors": [
"USERNAME_PASSWORD"
],
"USERNAME_PASSWORD": {
"credentials": [
"username",
"example-password"
]
},
"requestState": "{{requestState}}"
}
En la respuesta, el valor nextOp
indica lo que se puede enviar como valor op
en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit
se debe enviar en el siguiente paso. requestState
contiene datos contextuales necesarios para procesar la solicitud.
Paso 2: Enviar las credenciales del usuario
Envíe las credenciales del usuario como primer factor, que son el nombre de usuario y la contraseña. Para este paso, el cliente debe incluir los siguientes atributos:
-
credentials:
nombre de usuario y contraseña -
requestState:
recibido en la respuesta del paso 1 -
op:
indica al servidor qué tipo de operación desea el cliente
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:
{
"op": "credSubmit",
"credentials": {
"username": "{{username}}",
"password": "{{password}}"
},
"requestState": "{{requestState}}"
}
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"status": "success",
"ecId": "R^iCq18G000000000",
"accRecEnrollmentRequired": true,
"nextAuthFactors": [
"SMS",
"SECURITY_QUESTIONS",
"EMAIL"
],
"SMS": {
"credentials": [
"phoneNumber",
"countryCode"
]
},
"EMAIL": {
"userAllowedToSetRecoveryEmail": "true",
"primaryEmailVerified": "true",
"primaryEmail": "clarence.saladna@example.com",
"credentials": [
"recoveryEmail"
]
},
"nextOp": [
"createToken",
"createSession",
"enrollment"
],
"requestState": "IjhvZPILfadhlnih+4uTJ83CHf....0SDELTO0mTRqC+nNU"
}
En este ejemplo de caso de uso, el usuario debe inscribirse en la recuperación de cuentas (indicada por un valor true
para el atributo accRecEnrollmentRequired:true
). nextAuthFactors
indica los factores en los que el usuario puede inscribirse para la recuperación de cuenta.
En este ejemplo de caso de uso, la inscripción se envía en el siguiente paso para iniciar la inscripción de recuperación de cuenta para el usuario.
Paso 3: Iniciar inscripción de recuperación de cuenta
Este paso inicia la inscripción por SMS. El cliente debe incluir los siguientes atributos:
op
: indica al servidor qué tipo de operación desea el clienteauthFactor
: define el factor de autenticación en el que el usuario desea inscribirsephoneNumber
: define el número de teléfono al que se enviará el texto SMScountryCode
: define el código de país del número de teléfono al que se enviará el texto SMSrequestState
: recibido en la respuesta del paso 2
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:
{
"op":"enrollment",
"authFactor":"SMS",
"credentials":{
"phoneNumber":"1122334455",
"countryCode":"+44"
},
"requestState":"{{requestState}}"
}
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la solicitud con formato JSON:
{
"status": "success",
"ecId": "R^iCq19G000000000",
"displayName": "+44XXXXXXXX455",
"SMS": {
"credentials": [
"otpCode"
]
},
"nextOp": [
"credSubmit",
"resendCode",
"enrollment"
],
"requestState": "Y4sMHf7izgxcspF6zr...Y3GXLjjudeRMM2ZNty4E"
}
En la respuesta, los valores nextOp
indican lo que se puede enviar como valor de operación en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit
se envía en el siguiente paso. otpCode
se envía mediante SMS al dispositivo del usuario.
Paso 4: Enviar credenciales de factor
op
: indica al servidor qué tipo de operación desea el clienterequestState
: recibido en la respuesta del paso 3
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST en formato JSON para enviar las credenciales de factor:
{
"op":"credSubmit",
"credentials":{
"otpCode":"974311"
},
"requestState":"{{requestState}}"
}
Ejemplo de respuesta
El estado correcto aparece en la respuesta cuando la verificación optCode se realiza correctamente. En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"status": "success",
"ecId": "R^iCq1BG000000000",
"accRecEnrollmentRequired": false,
"displayName": "+44XXXXXXXX455",
"nextOp": [
"createToken",
"createSession",
"enrollment"
],
"requestState": "BKbGp43pwZad3zMSePWu7R47Va6myZdNY...vRVFN2FFQKIoDto"
}
En la respuesta, el valor accRecEnrollmentRequired
se define en false
porque la inscripción en la cuenta se ha realizado correctamente. Los valores nextOp
indican lo que se puede enviar como valor op
en la siguiente solicitud. El valor nextOp
"enrollment" permite al usuario cambiar a otro factor para inscribirse en la recuperación de cuenta. En este ejemplo de caso de uso, createToken
se envía en el siguiente paso.
Paso 5: Creación del token de autenticación
op
: indica al servidor qué tipo de operación desea el cliente requestState: recibida en la respuesta del paso 4requestState
: recibido en la respuesta del paso 4
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:
{
"op":"createToken",
"requestState":"{{requestState}}"
}
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"authnToken": "{{authnToken}}",
"status": "success",
"ecId": "R^iCq1FG000000000"
}
Autenticación de Nombre de Usuario y Contraseña e Inscripción en Recuperación de Cuentas y MFA
Este caso de uso proporciona un ejemplo paso a paso del uso de la API de autenticación de dominios de identidad para autenticarse con las credenciales de un usuario y, a continuación, inscribirse en la recuperación de cuenta y la autenticación multifactor (MFA).
- Utilice esta API de autenticación solo si va a crear su propia experiencia de conexión integral mediante el desarrollo de una aplicación de conexión personalizada para que la utilicen los dominios de identidad.
- Esta API de autenticación no se puede utilizar para integrar sus aplicaciones con dominios de identidad con fines de conexión única.
Descargue la recopilación de ejemplos de casos de uso de autenticación de dominios de identidad y el archivo de variables globales de la carpeta idcs-authn-api-rest-clients en el repositorio idm-samples GitHub y, a continuación, impórtelos en Postman.
- Paso 1: Inicio del flujo de autenticación
- Paso 2: Enviar las credenciales del usuario
- Paso 3: Iniciar inscripción de recuperación de cuenta
- Paso 4: Enviar credenciales de factor
- Paso 5: Creación del token de autenticación
- Paso 6: Establecer SMS como factor de MFA predeterminado en solapamiento
- Paso 7: Creación del token de autenticación
En estos pasos se asume que la recuperación de cuenta y la autenticación multifactor están activadas y que se crea una política de conexión para la autenticación multifactor. Consulte Configuración de la recuperación de cuenta y Configuración de los valores de autenticación multifactor.
Paso 1: Inicio del flujo de autenticación
Obtenga el requestState
inicial para iniciar el flujo de autenticación.
Ejemplo de solicitud
En el siguiente ejemplo se muestra la solicitud con formato cURL:
curl -X GET
-H "Content-Type: application/json"
-H "Authorization: Bearer {{access_token_value}}"
https://<domainURL>/sso/v1/sdk/authenticate?appName={{app_name}}
appName
es opcional. appName
es el nombre de la aplicación a la que el cliente desea acceder. Si se proporciona appName
, se procesan las políticas de conexión específicas de la aplicación y se desafía al cliente por los factores necesarios en función de esa política.Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"status": "success",
"ecId": "ecId",
"nextOp": [
"credSubmit"
],
"nextAuthFactors": [
"USERNAME_PASSWORD"
],
"USERNAME_PASSWORD": {
"credentials": [
"username",
"example-password"
]
},
"requestState": "{{requestState}}"
}
En la respuesta, el valor nextOp
indica lo que se puede enviar como valor op
en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit
se debe enviar en el siguiente paso. requestState
contiene datos contextuales necesarios para procesar la solicitud.
Paso 2: Enviar las credenciales del usuario
Envíe las credenciales del usuario como primer factor, que son el nombre de usuario y la contraseña. Para este paso, el cliente debe incluir los siguientes atributos:
-
credentials:
nombre de usuario y contraseña -
requestState:
recibido en la respuesta del paso 1 -
op:
indica al servidor qué tipo de operación desea el cliente
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:
{
"op": "credSubmit",
"credentials": {
"username": "{{username}}",
"password": "{{password}}"
},
"requestState": "{{requestState}}"
}
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"status": "success",
"ecId": "HI^kd1M0000000000",
"accRecEnrollmentRequired": true,
"nextAuthFactors": [
"SMS",
"SECURITY_QUESTIONS",
"EMAIL"
],
"SMS": {
"credentials": [
"phoneNumber",
"countryCode"
]
},
"EMAIL": {
"userAllowedToSetRecoveryEmail": "true",
"primaryEmailVerified": "true",
"primaryEmail": "clarence.saladna@example.com",
"credentials": [
"recoveryEmail"
]
},
"nextOp": [
"createToken",
"createSession",
"enrollment"
],
"requestState": "wtyRQpBzFZnuGMQvLNRotKfRIlgliWNc8sxipU....41zjKQcvdzk2bmvWs"
}
En este ejemplo de caso de uso, el usuario debe inscribirse en la recuperación de cuentas (indicada por un valor true
para el atributo accRecEnrollmentRequired:true
). nextAuthFactors
indica los factores en los que el usuario puede inscribirse para la recuperación de cuenta.
En este ejemplo de caso de uso, la inscripción se envía en el siguiente paso para iniciar la inscripción de recuperación de cuenta para el usuario.
Paso 3: Iniciar inscripción de recuperación de cuenta
Este paso inicia la inscripción por SMS. El cliente debe incluir los siguientes atributos:
op
: indica al servidor qué tipo de operación desea el clienteauthFactor
: define el factor de autenticación en el que el usuario desea inscribirsephoneNumber
: define el número de teléfono al que se enviará el texto SMScountryCode
: define el código de país del número de teléfono al que se enviará el texto SMSrequestState
: recibido en la respuesta del paso 2
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:
{
"op":"enrollment",
"authFactor":"SMS",
"credentials":{
"phoneNumber":"1122334455",
"countryCode":"+44"
},
"requestState":"{{requestState}}"
}
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la solicitud con formato JSON:
{
"status": "success",
"ecId": "HI^kd1N0000000000",
"displayName": "+44XXXXXXXX213",
"SMS": {
"credentials": [
"otpCode"
]
},
"nextOp": [
"credSubmit",
"resendCode",
"enrollment"
],
"requestState": "FnwYT23S0qo+RHXN3Sx80D3....8CsoT3QezVbynT3LfZY3+sXN5E8OtEdM"
}
En la respuesta, los valores nextOp
indican lo que se puede enviar como valor de operación en la siguiente solicitud. En este ejemplo de caso de uso, credSubmit
se envía en el siguiente paso. otpCode
se envía mediante SMS al dispositivo del usuario. Las credenciales indican al usuario qué entrada se necesita transferir en la siguiente solicitud.
Paso 4: Enviar credenciales de factor
requestState
que se recibieron en la respuesta del paso 3. Tenga en cuenta que la carga útil de solicitud no contiene el atributo authFactor
porque requestState
lo contiene. El cliente debe incluir los siguientes atributos:op
: indica al servidor qué tipo de operación desea el clienterequestState
: recibido en la respuesta del paso 3
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST en formato JSON para enviar las credenciales de factor:
{
"op":"credSubmit",
"credentials":{
"otpCode":"974311"
},
"requestState":"{{requestState}}"
}
Ejemplo de respuesta
El estado correcto aparece en la respuesta cuando la verificación optCode
se realiza correctamente. En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"status": "success",
"ecId": "HI^kd1P0000000000",
"accRecEnrollmentRequired": false,
"displayName": "+44XXXXXXXX455",
"nextOp": [
"createToken",
"createSession",
"enrollment"
],
"requestState": "Z+ysro8gFyPPT5bI9C/RykLfRrq5rBXCOO68/wZcgkllw765qd7SNvhRN6ZHp0Xiw2FIN9nOeio7SpsEAlYxO2xQ/1fF5lAjo0jwJEzIgSRt8xj/vAQeSLhX+PRm2a1rRYHwSa9uFcUBkNA.....KP7CPh2/yrdZF4WpbI"
}
En la respuesta, el valor accRecEnrollmentRequired
se define en false
porque la inscripción en la cuenta se ha realizado correctamente. Los valores nextOp
indican lo que se puede enviar como valor op
en la siguiente solicitud. El valor nextOp
"enrollment" permite al usuario cambiar a otro factor para inscribirse en la recuperación de cuenta. En este ejemplo de caso de uso, createToken
se envía en el siguiente paso.
Paso 5: Creación del token de autenticación
op
: indica al servidor qué tipo de operación desea que reciba el cliente requestState en la respuesta del paso 4requestState
: recibido en la respuesta del paso 4
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:
{
"op":"createToken",
"requestState":"{{requestState}}"
}
Ejemplo de respuesta
En el siguiente ejemplo se muestra el contenido de la respuesta con formato JSON:
{
"status": "success",
"ecId": "HI^kd1Q0000000000",
"nextAuthFactors": [
"TOTP",
"SECURITY_QUESTIONS",
"SMS",
"EMAIL",
"PUSH"
],
"EnrolledAccountRecoveryFactorsDetails": {
"SMS": {
"credentials": [
"accountRecoveryFactor"
],
"enrolledDevices": [
{
"deviceId": "3ed9b2ed366441fb91c9277abd694348",
"displayName": "+44XXXXXXXX455"
}
]
},
"EMAIL": {
"credentials": [
"accountRecoveryFactor"
],
"enrolledDevices": [
{
"displayName": "clarence.saladna@example.com"
}
]
},
"enrolledAccRecFactorsList": [
"SMS",
"EMAIL"
]
},
"nextOp": [
"enrollment"
],
"mfaSettings": {
"enrollmentRequired": true
},
"requestState": "YN9sdSJiNtD5lOEKt33paDa9Ezs5ZZhZhF3C1BsDCuMdVVNqt1RmA3d3SppmnVOIP3uYrErQNYADHCIQLrXgmxpxReUzdcFDArlejaaph3qWctYvLQiIsBwixsHgTOfQiDkzyjN8JZiX/gqbkTEmHi1S3EtjYXuw7qCcwi...G8ZnyfTrcZtKEpaDDj7CtWF/+LIwAEQLvFaXvkOK4P4"
}
En la respuesta, como se necesita MFA, enrollmentRequired
tiene el valor true
en mfaSettings
. Como resultado, no se emite ningún token. EnrolledAccountRecoveryFactorsDetails
muestra los factores de recuperación de cuenta en los que se ha inscrito el usuario. Los valores nextOp
indican lo que se puede enviar como valor op
en la siguiente solicitud. En este ejemplo, el valor nextOp
"enrollment" indica que el usuario se debe inscribir en MFA.
Paso 6: Establecer SMS como factor de MFA predeterminado en solapamiento
Este paso indica que el cliente debe inscribirse en MFA.
El cliente debe incluir los siguientes atributos:
authFactor
: indica en qué factor inscribirse para MFAaccountRecoveryFactor
: si se define en true, indica que el usuario desea reutilizar el factor de recuperación de cuenta ya inscrito para MFA.
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:
{
"op":"enrollment",
"authFactor": "SMS",
"credentials":{
"accountRecoveryFactor" : true
},
"requestState": "{{requestState}}"
}
Ejemplo de respuesta
{
"status": "success",
"ecId": "HI^kd1R0000000000",
"nextOp": [
"createToken",
"createSession",
"enrollment"
],
"requestState": "7J6m/Z1PxXQZp4pigzt1F0CXp0kotX.....WXP2knQa16MNj5E8"
}
En la respuesta, los valores nextOp
indican lo que se puede enviar como valor de operación en la siguiente solicitud. El valor nextOp
"enrollment" permite al usuario inscribir un factor adicional para MFA. En este ejemplo de caso de uso, createToken
se envía en el siguiente paso.
Paso 7: Creación del token de autenticación
authnFactors
y necesita una sesión creada. Según lo definido para la política, el servidor valida que no se necesita ninguna otra evaluación de factores y responde con el token o deniega el acceso. El cliente debe incluir los siguientes atributos:op
: indica al servidor qué tipo de operación desea el clienterequestState
: recibido en la respuesta del paso 6
Ejemplo de solicitud
En el siguiente ejemplo se muestra el contenido de la solicitud POST con formato JSON:
{
"op":"createToken",
"requestState":"{{requestState}}"
}
Ejemplo de respuesta
{
"authnToken": "{{authnToken}}",
"status": "success",
"ecId": "HI^kd1W0000000000"
}
Autenticación con nombre de usuario y contraseña y Mantener sesión iniciada
Active y configure Mantenerme conectado (KMSI) para que los usuarios puedan acceder a un dominio de identidad sin tener que conectarse repetidamente.
Utilice los siguientes pasos para configurar KMSI mediante interfaces de aplicación programáticas.
- Paso 1: Activar KMSI para un dominio de identidad
- Paso 2: Inicio del flujo de autenticación
- Paso 3: Enviar las credenciales del usuario con KMSI
- Paso 4: Vuelva a emitir authnToken después de la caducidad de la sesión
- Paso 5: Enviar credenciales de usuario con flujo de KMSI y MFA
- Paso 6: Vuelva a emitir authnToken después de la caducidad de la sesión cuando se defina un factor de MFA
Este tema también contiene las siguientes secciones:
- Flujo kmsiToken con requestState
- Cambios en /sso/v1/sdk/secure/session
- Firma de carga útil para /autorizar llamadas iniciadas
Antes de empezar
- Asegúrese de que se haya activado KMSI para su cuenta de Cloud. Debe emitir una solicitud de servicio (SR) con los Servicios de Soporte Oracle para activar KMSI. Especifique el siguiente nombre de función en la solicitud de servicio:
access.kmsi.support
. Consulte Open a Support Request. - Consulte las siguientes secciones de este tema:
Paso 1: Activar KMSI para un dominio de identidad
- Obtenga el token de acceso de administrador del dominio de identidad para su cuenta.
- Ejecute
GET
en el punto final/admin/v1/KmsiSettings/KmsiSettings
. El sistema devuelveKmsiSettings
. - Actualice los atributos necesarios y ejecute
PUT
en el punto final/admin/v1/KmsiSettings/KmsiSettings
.
tokenValidityInDays
- Introduzca el número de días que los usuarios pueden permanecer conectados antes de que se desconecten automáticamente.
kmsiEnabled
- Indica si KMSI está activado para el dominio de identidad.
maxAllowedSessions
- Introduzca el número máximo de sesiones conectadas que puede tener un usuario.
Solicitud de ejemplo
{
"schemas": [
"urn:ietf:params:scim:schemas:oracle:idcs:KmsiSettings"
],
"tokenValidityInDays": 2160,
"kmsiEnabled": true,
"maxAllowedSessions": 5,
"id": "KmsiSettings"
}
Paso 2: Inicio del flujo de autenticación
Obtenga el requestState
inicial para iniciar el flujo de autenticación.
Ejemplo de solicitud
En el siguiente ejemplo se muestra la solicitud con formato cURL:
curl -X GET
-H "Content-Type: application/json"
-H "Authorization: Bearer {{access_token_value}}"
https://<domainURL>/sso/v1/sdk/authenticate?appName={{app_name}}
appName
es opcional. appName
es el nombre de la aplicación a la que el cliente desea acceder. Si se proporciona appName
, se procesan las políticas de conexión específicas de la aplicación y se desafía al cliente por los factores necesarios en función de esa política.Ejemplo de respuesta
{
"status": "success",
"ecId": "ZzK2c1^0000000000",
"nextOp": [
"credSubmit"
],
"nextAuthFactors": [
"USERNAME_PASSWORD"
],
"USERNAME_PASSWORD": {
"credentials": [
"username",
"password"
]
},
"keepMeSignedInEnabled": false,
"requestState": "FT7qI"
}
Observe el nuevo atributo keepMeSignedInEnabled
incluido en la respuesta. Esto indica que este dominio de identidad y esta aplicación admiten KMSI. Si tiene una interfaz personalizada, utilice este atributo para mostrar la opción Mantenerme conectado en la página de conexión.
Paso 3: Enviar las credenciales del usuario con KMSI
- Operación:
POST
-
Punto final:
/sso/v1/sdk/authenticate
Tenga en cuenta el nuevo atributo
keepMeSignedIn
incluido en la solicitud. Este atributo indica que el usuario desea utilizar KMSI.{
"op": "credSubmit",
"credentials": {
"username": "username",
"password": "Password"
},
"keepMeSignedIn": true,
"kmsiDeviceDisplayName": "Postman KeepMeSigned In",
"requestState": "requestState"
}
Si tiene una interfaz personalizada, use este atributo para mostrar la opción KMSI, marque el estado de la casilla de control (activada o desactivada) y envíe este parámetro para crear la sesión KMSI.
Ejemplo de respuesta
{
"authnToken": "QpfQIQ",
"kmsiToken": "ZJM",
"status": "success",
"ecId": "PR8Yf160000000000"
}
En el ejemplo de respuesta, observe el atributo kmsiToken
. Este token se puede utilizar para acceder a cualquier aplicación en el futuro sin necesidad de que un usuario vuelva a conectarse.
Paso 4: Vuelva a emitir authnToken después de la caducidad de la sesión
-
Operación:
POST
-
Punto final:
/sso/v1/sdk/authenticate
Ejemplo de solicitud
{
"op": "credSubmit",
"authFactor": "KMSI",
"appName": "AppName",
"kmsiToken": "{{kmsiToken}}"
}
Ejemplo de respuesta
{
"authnToken": "QpfQIQ",
"kmsiToken": "ZJM",
"status": "success",
"ecId": "PR8Yf160000000000"
}
Observe la operación credSubmit
con un nuevo authFactor
, appName
y kmsiToken
que se envían en la solicitud. SSO evalúa la solicitud y devuelve authnToken
y la última kmsiToken
actualizada en la respuesta. Se trata de un kmsiToken
refrescado y sustituye al token existente. Debe incluir este kmsiToken
refrescado en la siguiente solicitud.
Paso 5: Enviar credenciales de usuario con flujo de KMSI y MFA
Inicie GET
en /sso/v1/sdk/authenticate
desde el Paso 2: Inicio del flujo de autenticación.
-
Operación:
POST
-
Punto final:
/sso/v1/sdk/authenticate
Ejemplo de respuesta
{
"op": "credSubmit",
"credentials": {
"username": "username",
"password": "Password"
},
"keepMeSignedIn": true,
"kmsiDeviceDisplayName": "Postman KeepMeSigned In",
"requestState": "requestState"
}
Ejemplo de respuesta
{
"status": "success",
"ecId": "L371Y0xD000000000",
"displayName": "sswXXXXX@oracle.com",
"nextAuthFactors": [
"EMAIL-OTP/TOTP/SMS-OTP/PUSH/BYPASSCODE"
],
"EMAIL-OTP/TOTP/SMS-OTP/PUSH/BYPASSCODE": {
"credentials": [
"otpCode"
]
},
"nextOp": [
"credSubmit",
"getBackupFactors",
"resendCode"
],
"scenario": "AUTHENTICATION",
"requestState": "QQwppp+-",
"trustedDeviceSettings": {
"trustDurationInDays": 15
}
}
Después de obtener el código de acceso de un solo uso (OTP) en el dispositivo, agregue la OTP en la solicitud.
Ejemplo de solicitud
{
"op": "credSubmit",
"authFactor": "EMAIL-OTP/TOTP/SMS-OTP/PUSH/BYPASSCODE",
"credentials": {
"otpCode": "XXXX"
},
"requestState": "6tnX6Q4RGqe4Lq73WD0pQ"
}
La respuesta incluye authToken
y kmsiToken
. Se trata de un kmsiToken
refrescado.
Ejemplo de respuesta
{
"authnToken": "QpfQIQ",
"kmsiToken": "ZJM",
"status": "success",
"ecId": "PR8Yf160000000000"
}
Paso 6: Vuelva a emitir authnToken después de la caducidad de la sesión cuando se defina un factor de MFA
Cuando un usuario intenta conectarse mediante kmsiToken
y hay un segundo factor configurado, siempre se le solicita al usuario la autenticación del segundo factor. Solo después de una autenticación correcta, se enviarán authnToken
y kmsiToken
en la respuesta.
-
Operación:
POST
-
Punto final:
/sso/v1/sdk/authenticate
Ejemplo de solicitud
{
"op": "credSubmit",
"authFactor": "KMSI",
"appName": "AppName",
"kmsiToken": "{{kmsiToken}}"
}
La respuesta contiene un token de KMSI refrescado y una comprobación de MFA.
Ejemplo de respuesta
{
"status": "success",
"ecId": "pccFR1eG000000000",
"displayName": "XXXXX@oracle.com",
"nextAuthFactors": [
"EMAIL-OTP/TOTP/SMS-OTP/PUSH/BYPASSCODE"
],
"EMAIL-OTP/TOTP/SMS-OTP/PUSH/BYPASSCODE": {
"credentials": [
"otpCode"
]
},
"nextOp": [
"credSubmit",
"getBackupFactors",
"resendCode"
],
"scenario": "AUTHENTICATION",
"requestState": "+Dj6hQQ7id5V2gSGHGtCROb5n",
"trustedDeviceSettings": {
"trustDurationInDays": 15
},
"kmsiToken": "fxkLne3RtKI1c"
}
Repita el mismo proceso en el que se le pedirá de nuevo la OTP en el dispositivo. Proporcione la siguiente carga útil con la OTP. La respuesta debe incluir authnToken
.
Ejemplo de solicitud
{
"op": "credSubmit",
"authFactor": "EMAIL-OTP/TOTP/SMS-OTP/PUSH/BYPASSCODE",
"credentials": {
"otpCode": "XXXX"
},
"requestState": "6tnX6Q4RGqe4Lq73WD0pQ"
}
Ejemplo de respuesta
{
"authnToken": "QpfQIQ",
"status": "success",
"ecId": "PR8Yf160000000000"
}
Flujo kmsiToken con requestState
Utilice este flujo para soportar el contexto del explorador cuando posea el token KMSI, pero no la cookie KMSI. Después de la caducidad de la sesión, la aplicación realiza una llamada de autorización al sistema de identidad con redirectUrl
, state
, nonce
, etc. En la respuesta, el sistema de identidad devuelve requestState
dentro de loginCtx
. Este requestState junto con el token KMSI se transfiere para redirigir la aplicación necesaria después de ampliar la sesión.
-
Operación:
POST
-
Punto final:
/sso/v1/sdk/authenticate
authFactor
y autentica KMSI con el parámetro requestState
. Esto permite recuperar kmsiToken
con requestState
de loginCtx
. Si
requestState
y kmsiToken
no proceden de la misma aplicación, la solicitud se rechaza.Ejemplo de solicitud
{
"op": "credSubmit",
"authFactor": "KMSI",
"appName": "KMSIAdmin",
"kmsiToken": "{{kmsiToken}}",
"requestState": "{{requestState}}"
}
Ejemplo de respuesta
{
"authnToken": "QpfQIQ",
"kmsiToken": "ZJM",
"status": "success",
"ecId": "PR8Yf160000000000"
}
Cambios en /sso/v1/sdk/secure/session
KMSI necesita que se agregue un nuevo atributo al punto final /sso/v1/sdk/secure/session
. kmsiToken
se debe enviar al punto final desde la aplicación de conexión personalizada.
Ejemplo de solicitud | Ejemplo de respuesta |
---|---|
kmsiToken |
La nueva variable de publicación de formulario kmsiToken junto con authnToken o requestState se redirigirá a la aplicación junto con la cookie de sesión SSO y la cookie KMSI. |
Firma de carga útil para llamadas iniciadas de /authorize
- Cuando un usuario accede a cualquier aplicación web protegida por dominios de identidad, introduce su URL de aplicación, por ejemplo,
https://example.com/home/pages/profile
. - El sistema redirige a la llamada
/authorize
del dominio de identidad. - El dominio de identidad redirige al usuario a la página de conexión personalizada desplegada por el cliente.
- La aplicación de conexión alojada por el cliente recopila los parámetros de entrada y decodifica la entrada
loginCtx
. - El parámetro de entrada descifrado coincide con la llamada
GET
/sso/v1/sdk/authenticate
. - La carga útil contiene
keepMeSignedInEnabled
para identificar si KMSI está activado. - La aplicación de conexión personalizada recopila las credenciales y las envía al dominio de identidad.
- El dominio de identidad valida las credenciales y emite
kmsiToken
yauthnToken
. - La aplicación de conexión personalizada utiliza
authnToken
ykmsiToken
al realizar la llamada al punto final/sso/v1/sdk/secure/session
. La nueva sintaxis del punto final seguro se describe en Changes to /sso/v1/sdk/secure/session. - El dominio de identidad valida
authnToken
,kmsiToken
y, a continuación, el sistema de identidad emite la cookie de sesión SSO y la cookie KMSI. - Durante la sesión, la cookie KMSI se valida para ampliar la sesión sin volver a introducir las credenciales.