Usando a API de Autenticação para Desenvolver uma Página de Acesso Personalizada
Esse caso de uso fornece um exemplo passo a passo de uso da API REST de domínios de identidades para desenvolver uma página de acesso personalizada para um domínio de identidades.
Só use essa API de Autenticação se estiver criando sua própria experiência de log-in de ponta a ponta desenvolvendo um aplicativo de acesso personalizado para ser usado por domínios de identidades.
Essa API de Autenticação não pode ser usada para integrar seus aplicativos a domínios de identidades para fins de sign-on único.
A API Authenticate é baseada no conceito de uma máquina de estado. As respostas de solicitação informam a um cliente de aplicativo o que deve ser feito a seguir, em vez de exigir que os usuários tenham cookies de terceiros ativados em seus navegadores. Os cookies de terceiros ativados nos navegadores podem representar problemas, especialmente para aplicativos B2C em que os controles sobre o comportamento do usuário final não podem ser aplicados. O requestState fornecido em cada resposta de solicitação é usado na próxima solicitação, fornecendo ao cliente as informações necessárias para processar a solicitação e, em seguida, fornecendo o próximo conjunto de operações permitidas.
- Ajude a verificar as credenciais de nome de usuário e senha de um usuário como autenticação principal.
- Suportar inscrição de usuário com fatores MFA ativados pelo administrador
- Reforce a segurança da autenticação baseada em senha usando a Autenticação Multifator (MFA) exigindo verificação adicional, como usar um código de acesso único baseado em tempo ou um código de acesso SMS.
- Permita que seus usuários selecionem um SAML externo ou um Provedor de Identidades Social para autenticação.
Consulte a coleção Postman da API de Autenticação de domínios de identidades para obter exemplos extensivos de casos de uso de autenticação. Faça download da coleção e do arquivo de variáveis globais da pasta idcs-authn-api-rest-clients em GitHub e importe-os para o Postman.
- Autenticando um Provedor de Identidades SAML Externo
- Autenticando um Provedor de Identidades SAML Social
- Autenticando com um Provedor de Identidades SAML Externo e MFA
- Autenticando com Nome de Usuário e Senha
- Autenticando Nome de Usuário e Senha com Consentimento de Horário de Uso
- Gerando Token de Acesso Usando API de Autenticação
- Autenticando Nome de Usuário e Senha e Inscrevendo-se na Recuperação de Conta
- Autenticando Nome de Usuário e Senha e Inscrevendo-se na Recuperação de Conta e MFA
- Autenticando com Nome de Usuário e Senha e Inscrevendo-se na MFA
- Autenticando com Nome do Usuário, Senha e MFA
Autenticar e Códigos de Status de API de MFA Sob Demanda
Autenticando com um Provedor de Identidades SAML Externo
Este caso de uso discute as etapas para usar domínios de identidades para autenticação usando um Provedor de Identidades SAML externo (IdP).
- Use essa API de Autenticação somente se estiver criando sua própria experiência de log-in de ponta a ponta desenvolvendo um aplicativo de acesso personalizado para ser usado por domínios de identidades.
- Essa API de Autenticação não pode ser usada para integrar seus aplicativos a domínios de identidade para fins de sign-on único.
Faça download da coleção de exemplos de casos de uso de autenticação de domínios de identidades e do arquivo de variáveis globais da pasta idcs-authn-api-rest-clients no repositório GitHub de idm-samples e importe-os para o Postman.
Etapa 1: Iniciar o Fluxo de Autenticação
Um usuário abre uma janela do navegador para acessar uma página protegida.
/authorize. Isso inicia o processo de autenticação. Em vez de apresentar a página de acesso padrão, os domínios de identidades respondem criando e enviando um formulário HTML que contenha os parâmetros loginCtx e signature para o browser.Você deve expor um ponto final para receber a publicação do formulário e ler os dois valores de parâmetro.
Exemplo de POST do Formulário HTML
Veja a seguir um exemplo de POST de Formulário HTML que os domínios de identidade retornam para chamar a página de acesso 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 é criptografado com based64, o aplicativo de acesso personalizado deve decriptografar o loginCtx fazendo o seguinte:- Decodificar usando um decodificador base64 para obter os dados binários criptografados
- Usar o nome do tenant e gerar uma chave para decriptografia
- Descriptografar os dados com a chave e os dados binários
Exemplo de Lógica de Decriptografia para loginCtx Criptografado no Java
Veja a seguir um exemplo de lógica de decriptografia:
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;
}
Exemplo de Resposta
A resposta deve ser semelhante ao seguinte exemplo:
{
"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 contém alguns atributos importantes:- requestState: O estado do processo de autenticação. Ele precisa ser usado em POSTs e GETs futuros para pontos finais da API de Autenticação de domínios de identidade.
- nextOp: A próxima operação que o aplicativo de acesso personalizado deve executar.
- nextAuthFactors: Os possíveis fatores de autenticação que a página de acesso deve apresentar.
Os valores desses atributos definem qual fator de autenticação, provedores de identidade e provedores sociais são apresentados na página de acesso. A página de acesso aparece contendo os valores decriptografados do parâmetro loginCtx junto com o token de acesso. A página de acesso inclui o JavaScript usado para executar chamadas AJAX para domínios de identidades.
Etapa 2: Selecionar um Provedor de Identidades SAML
/sso/v1/sdk/idp. Para esta etapa, os seguintes atributos devem ser incluídos:requestState:recebido na resposta da Etapa 1idpName:nome do IdP recebido na resposta da Etapa 1idpType:tipo de IdP recebido na resposta da Etapa 1 (neste exemplo, é SAML)idpId:id do IdP recebido na resposta da Etapa 1appName:nome do aplicativo ao qual o cliente deseja acessar- ID do cliente
clientID:do aplicativo que o browser está tentando acessar - Parâmetro
authorization:necessário para Idp seguro
Exemplo de Código POST de Formulário HTML para Selecionar um 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");
};Exemplo de Solicitação
Veja a seguir um exemplo do conteúdo do FORM POST no ponto final /sso/v1/sdk/secure/idp:
requestState=value&idpName=value&idpType=SAML&idpId=value&appName=name&clientID=value&authorization=accesstoken
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato HTTP padrão:
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
Os domínios de identidades processam a solicitação e redirecionam o browser para o IdP externo selecionado para autenticação e autorização. Quando o IdP externo é concluído, o browser é redirecionado para domínios de identidades. Os domínios de identidade validam a resposta da asserção e verificam se a autenticação adicional, como MFA, é necessária.
Se a autenticação adicional não for necessária, os domínios de identidade criarão a sessão e redirecionarão o browser para o URL de destino. Ou os domínios de identidades criam um FORM POST de envio automático HTML para a página de acesso personalizada que contém o authnToken. A página de acesso personalizada cria a sessão. Consulte Criando uma Sessão.
Autenticando com um Provedor de Identidades Social
Este caso de uso discute as etapas para usar domínios de identidade para autenticação usando um Provedor de Identidades Social (IdP), como Facebook ou Google.
- Use essa API de Autenticação somente se estiver criando sua própria experiência de log-in de ponta a ponta desenvolvendo um aplicativo de acesso personalizado para ser usado por domínios de identidades.
- Essa API de Autenticação não pode ser usada para integrar seus aplicativos a domínios de identidade para fins de sign-on único.
Faça download da coleção de exemplos de casos de uso de autenticação de domínios de identidades e do arquivo de variáveis globais da pasta idcs-authn-api-rest-clients no repositório GitHub de idm-samples e importe-os para o Postman.
Etapa 1: Iniciar o Fluxo de Autenticação
Um usuário abre uma janela do navegador para acessar uma página protegida.
/authorize. Isso inicia o processo de autenticação. Em vez de apresentar a página de acesso padrão, os domínios de identidades respondem criando e enviando um formulário HTML que contenha os parâmetros loginCtx e signature para o browser.Você deve expor um ponto final para receber a publicação do formulário e ler os dois valores de parâmetro.
Exemplo de POST do Formulário HTML
Veja a seguir um exemplo de POST de Formulário HTML que os domínios de identidade retornam para chamar a página de acesso 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 é criptografado com based64, o aplicativo de acesso personalizado deve decriptografar o loginCtx fazendo o seguinte:Exemplo de Lógica de Decriptografia para loginCtx Criptografado no Java
Veja a seguir um exemplo de lógica de decriptografia:
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;
}
Exemplo de Resposta
A resposta deve ser semelhante ao seguinte exemplo:
{
"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 contém alguns atributos importantes:Os valores desses atributos definem qual fator de autenticação, provedores de identidade e provedores sociais são apresentados na página de acesso. A página de acesso aparece contendo os valores decriptografados do parâmetro loginCtx junto com o token de acesso. A página de acesso inclui o JavaScript usado para executar chamadas AJAX para domínios de identidades.
Etapa 2: Selecionar um Provedor de Identidades Social
/sso/v1/sdk/idp. Para esta etapa, os seguintes atributos devem ser incluídos:Exemplo de Código POST do Formulário HTML para Selecionar um 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");
};
Exemplo de Solicitação
Veja a seguir um exemplo do conteúdo do FORM POST no ponto final /sso/v1/sdk/secure/idp:
requestState=value&idpName=value&idpType=Social&idpId=value&appName=name&clientID=value&authorization=accesstoken
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no 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
Os domínios de identidades processam a solicitação e redirecionam o browser para o IdP social selecionado para autenticação e autorização. Quando o IdP social é concluído, o browser é redirecionado para domínios de identidades. Os domínios de identidade validam a resposta da asserção e verificam se a autenticação adicional, como MFA, é necessária.
Se a autenticação adicional não for necessária, os domínios de identidade criarão a sessão e redirecionarão o browser para o URL de destino. Ou os domínios de identidades criam um FORM POST de envio automático HTML para a página de acesso personalizada que contém o authnToken. A página de acesso personalizada cria a sessão. Consulte Criando uma Sessão.
Autenticando com um Provedor de Identidades SAML Externo e MFA
Este caso de uso discute as etapas para usar domínios de identidade para autenticação usando um Provedor de Identidades SAML externo (IdP) e Autenticação Multifator (MFA).
- Use essa API de Autenticação somente se estiver criando sua própria experiência de log-in de ponta a ponta desenvolvendo um aplicativo de acesso personalizado para ser usado por domínios de identidades.
- Essa API de Autenticação não pode ser usada para integrar seus aplicativos a domínios de identidade para fins de sign-on único.
Faça download da coleção de exemplos de casos de uso de autenticação de domínios de identidades e do arquivo de variáveis globais da pasta idcs-authn-api-rest-clients no repositório GitHub de idm-samples e importe-os para o Postman.
Etapa 1: Iniciar o Fluxo de Autenticação
Um usuário abre uma janela do navegador para acessar uma página protegida.
/authorize. Isso inicia o processo de autenticação. Em vez de apresentar a página de acesso padrão, os domínios de identidades respondem criando e enviando um formulário HTML que contenha os parâmetros loginCtx e signature para o browser.Você deve expor um ponto final para receber a publicação do formulário e ler os dois valores de parâmetro.
Exemplo de POST do Formulário HTML
Veja a seguir um exemplo de POST de Formulário HTML que os domínios de identidade retornam para chamar a página de acesso 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 é criptografado com based64, o aplicativo de acesso personalizado deve decriptografar o loginCtx fazendo o seguinte:- Decodificar usando um decodificador base64 para obter os dados binários criptografados
- Usar o nome do tenant e gerar uma chave para decriptografia
- Descriptografar os dados com a chave e os dados binários
Exemplo de Lógica de Decriptografia para loginCtx Criptografado no Java
Veja a seguir um exemplo de lógica de decriptografia:
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;
}
Exemplo de Resposta
A resposta deve ser semelhante ao seguinte exemplo:
{
"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 contém alguns atributos importantes:- requestState: O estado do processo de autenticação. Ele precisa ser usado em POSTs e GETs futuros para pontos finais da API de Autenticação de domínios de identidade.
- nextOp: A próxima operação que o aplicativo de acesso personalizado deve executar.
- nextAuthFactors: Os possíveis fatores de autenticação que a página de acesso deve apresentar.
Os valores desses atributos definem qual fator de autenticação, provedores de identidade e provedores sociais são apresentados na página de acesso. A página de acesso aparece contendo os valores decriptografados do parâmetro loginCtx junto com o token de acesso. A página de acesso inclui o JavaScript usado para executar chamadas AJAX para domínios de identidades.
Etapa 2: Selecionar um Provedor de Identidades Externo
/sso/v1/sdk/idp. Para esta etapa, os seguintes atributos devem ser incluídos:requestState:recebido na resposta da Etapa 1idpName:nome do IdP recebido na resposta da Etapa 1idpType:tipo de IdP recebido na resposta da Etapa 1 (neste exemplo, é SAML)idpId:id do IdP recebido na resposta da Etapa 1appName:nome do aplicativo ao qual o cliente deseja acessar- ID do cliente
clientID:do aplicativo que o browser está tentando acessar - Parâmetro
authorization:necessário para Idp seguro
Exemplo de Código POST do Formulário HTML para Selecionar um 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");
};Exemplo de Solicitação
Veja a seguir um exemplo do conteúdo do FORM POST no ponto final /sso/v1/sdk/secure/idp:
requestState=value&idpName=value&idpType=SAML&idpId=value&appName=name&clientID=value&authorization=accesstoken
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato HTTP padrão:
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
Os domínios de identidades processam a solicitação e redirecionam o browser para o IdP externo selecionado para autenticação e autorização. Quando o IdP externo é concluído, ele redireciona o browser para domínios de identidades, o que, em seguida, redireciona o browser para iniciar a Verificação em 2 Etapas.
Etapa 3: Autenticar Usando o Fator Preferido (SMS)
As etapas iniciais para iniciar a Verificação em 2 Etapas são semelhantes à Etapa 1. Os domínios de identidades criam e submetem um formulário HTML que contém os parâmetros loginCtx e signature criptografados. Consulte a Etapa 1 para obter informações detalhadas sobre o formulário POST e como descriptografar.
Depois que o parâmetro loginCtx for decriptografado, a resposta deverá ser semelhante ao seguinte exemplo:
{
"status": "success",
"displayName": "Joe's iPhone",
"nextAuthFactors": [
"SMS"
],
"SMS": {
"credentials": [
"otpCode"
]
},
"nextOp": [
"credSubmit",
"getBackupFactors",
"resendCode"
],
"requestState": "QjyV3ueFrGQCO.....84gQw2UUm2V7s",
"trustedDeviceSettings": {
"trustDurationInDays": 15
}
}
loginCtx contém alguns atributos importantes:- requestState: O estado do processo de autenticação. Ele precisa ser usado em POSTs e GETs futuros para pontos finais da API de Autenticação de domínios de identidade.
- nextOp: A próxima operação que o aplicativo de acesso personalizado deve executar.
- nextAuthFactors: Os possíveis fatores de autenticação que a página de acesso deve apresentar.
Os valores desses atributos definem qual fator de autenticação (neste exemplo, é SMS) apresentar na página de acesso. O usuário insere o código de acesso único que recebe em seu dispositivo.
op:informa ao servidor que tipo de operação o cliente desejaotpCode:o código enviado para o dispositivo do usuáriorequestState:recebido na resposta da Etapa 2
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON para concluir a autenticação usando o método preferencial:
{
"op":"credSubmit",
"credentials":{
"otpCode":"108685"
},
"requestState":"{{requestState}}"
}
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON:
{
"authnToken": "eyJraWQiOiJT.....kLbxxL97U_0Q",
"status": "success"
}
Uma sessão deve ser criada. Após a criação da sessão, o navegador é redirecionado para o URL solicitado originalmente. Consulte Criando uma Sessão.
Criando uma Sessão
Esse caso de uso fornece um exemplo de uso de domínios de identidades para criar uma sessão após a autenticação, como após a autenticação usando a MFA.
Só use essa API de Autenticação se estiver criando sua própria experiência de log-in de ponta a ponta desenvolvendo um aplicativo de acesso personalizado para ser usado por domínios de identidades.
Essa API de Autenticação não pode ser usada para integrar seus aplicativos a domínios de identidades para fins de sign-on único.
Consulte os outros casos de uso em Usando a API de Autenticação para obter informações sobre como usar a API de Autenticação.
Envie o authnToken e o requestState como um FORM POST quando o cliente terminar de fazer autenticação e MFA, e precisar criar uma sessão. Para essa etapa, createSession deve ser listado como um valor de atributo nextOp na última resposta recebida, e o FORM POST deve incluir um dos atributos a seguir.
/sso/v1/sdk/secure/session:requestState:recebido na última respostaOU
authnToken:recebido na última respostaAND
- Parâmetro
authorization:necessário para sessão segura
Exemplo de Solicitação
Veja a seguir um exemplo do conteúdo do FORM POST no ponto 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>Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato HTTP padrão:
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
Se createSession não estiver listado como um valor para o parâmetro nextOp na última resposta recebida, talvez você precise criar um token antes de criar uma sessão. Se createSession estiver listado como um valor para nextOp, o ponto final sdk/session poderá ser chamado diretamente usando apenas requestState.
Exemplo de Solicitação
O exemplo a seguir mostra a solicitação de token para o ponto final /sso/v1/sdk/authenticate no formato JSON:
{
"op":"createToken",
"requestState":"{{requestState}}"
}
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON:
{
"authnToken":"eyJraWQiOiJ....4IacnWKSQ",
"status":"success"
}
O servidor verifica se nenhuma outra avaliação de fator é necessária. Se nenhuma outra avaliação for necessária, o token será enviado na resposta.
Autenticando com Nome de Usuário e Senha
Esse caso de uso fornece um exemplo passo a passo de uso da API de Autenticação de domínios de identidades para autenticação com as credenciais de um usuário.
- Use essa API de Autenticação somente se estiver criando sua própria experiência de log-in de ponta a ponta desenvolvendo um aplicativo de acesso personalizado para ser usado por domínios de identidades.
- Essa API de Autenticação não pode ser usada para integrar seus aplicativos a domínios de identidade para fins de sign-on único.
Faça download da coleção de exemplos de casos de uso de autenticação de domínios de identidades e do arquivo de variáveis globais da pasta idcs-authn-api-rest-clients no repositório GitHub de idm-samples e importe-os para o Postman.
Utilize as seguintes etapas para o caso de uso.
Etapa 1: Iniciar o Fluxo de Autenticação
Obtenha o requestState inicial para iniciar o fluxo de autenticação.
Exemplo de Solicitação
O exemplo a seguir mostra a solicitação no 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}}
O
appName é opcional. O appName é o nome do Aplicativo que o cliente deseja acessar. Se um appName for fornecido, as políticas de sign-on específicas do Aplicativo serão processadas e o cliente será desafiado pelos fatores necessários com base nessa política.Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON:
{
"status": "success",
"ecId": "ecId",
"nextOp": [
"credSubmit"
],
"nextAuthFactors": [
"USERNAME_PASSWORD"
],
"USERNAME_PASSWORD": {
"credentials": [
"username",
"example-password"
]
},
"requestState": "{{requestState}}"
}
Na resposta, o valor nextOp indica o que pode ser enviado como o valor op na próxima solicitação. Neste exemplo de caso de uso, credSubmit deve ser enviado na próxima etapa. O requestState contém dados contextuais necessários para processar a solicitação.
Etapa 2: Enviar as Credenciais do Usuário
Submeta as credenciais do usuário como o primeiro fator, que são o nome de usuário e a senha. Para esta etapa, o cliente deve incluir os seguintes atributos:
-
credentials:nome de usuário e senha -
requestState:recebido na resposta da Etapa 1 -
op:informa ao servidor que tipo de operação o cliente deseja
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON:
{
"op": "credSubmit",
"credentials": {
"username": "{{username}}",
"password": "{{password}}"
},
"requestState": "{{requestState}}"
}
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON:
{
"authnToken": "eyJraWQiOiJT.....UKofudtemmJE",
"status": "success"
}
Exemplo de Resposta de Erro
O exemplo a seguir mostra o conteúdo da resposta no formato JSON quando o nome de usuário ou a senha fornecida é inválido:
{
"status": "failed",
"cause": [
{
"message": "You entered an incorrect username or password.",
"code": "AUTH-3001"
}
],
"requestState": "e5kwGYx57taQ.....jyg3nEDFya"
}
Autenticando Nome de Usuário e Senha com Consentimento de Horário de Uso
Esse caso de uso fornece um exemplo passo a passo de uso da API de Autenticação de domínios de identidades para autenticação com as credenciais de um usuário com consentimento de horário de uso. Quando o usuário aceita o consentimento, o usuário é redirecionado para essa página do aplicativo.
- Use essa API de Autenticação somente se estiver criando sua própria experiência de log-in de ponta a ponta desenvolvendo um aplicativo de acesso personalizado para ser usado por domínios de identidades.
- Essa API de Autenticação não pode ser usada para integrar seus aplicativos a domínios de identidade para fins de sign-on único.
Faça download da coleção de exemplos de casos de uso de autenticação de domínios de identidades e do arquivo de variáveis globais da pasta idcs-authn-api-rest-clients no repositório GitHub de idm-samples e importe-os para o Postman.
Etapa 1: Iniciar o Fluxo de Autenticação
Obtenha o requestState inicial para iniciar o fluxo de autenticação.
Exemplo de Solicitação
O exemplo a seguir mostra a solicitação no 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}}
O
appName é opcional. O appName é o nome do Aplicativo que o cliente deseja acessar. Se um appName for fornecido, as políticas de sign-on específicas do Aplicativo serão processadas e o cliente será desafiado pelos fatores necessários com base nessa política.Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON:
{
"status": "success",
"ecId": "ecId",
"nextOp": [
"credSubmit"
],
"nextAuthFactors": [
"USERNAME_PASSWORD"
],
"USERNAME_PASSWORD": {
"credentials": [
"username",
"example-password"
]
},
"requestState": "{{requestState}}"
}
Na resposta, o valor nextOp indica o que pode ser enviado como o valor op na próxima solicitação. Neste exemplo de caso de uso, credSubmit deve ser enviado na próxima etapa. O requestState contém dados contextuais necessários para processar a solicitação.
Etapa 2: Enviar as Credenciais do Usuário sem MFA)
credentials:nome de usuário e senharequestState:recebido na resposta da Etapa 1op:informa ao servidor que tipo de operação o cliente deseja
Se o nome de usuário e as senhas forem válidos, o servidor responderá com a instrução TOU no local especificado no perfil do usuário. O servidor também solicita que o usuário forneça sua credencial de consentimento na próxima solicitação. Se a instrução TOU não estiver presente na configuração regional do usuário fr, a resposta 401 com a mensagem de erro AUTH-3036 : A Instrução de Termos de Uso para a configuração regional fr não será adicionada será exibida.
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON para o ponto final /sso/v1/sdk/authenticate:
{
"op":"credSubmit",
"credentials":{
"username":"{{username}}",
"password":"{{password}}"
},
"requestState":"{{requestState}}"
}
}
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON quando a configuração regional do usuário é adicionada:
{
"nextOp": [
"acceptTOU"
],
"TOU": {
"statement": "This is a placeholder text. Customers must provide the actual Terms of Use.",
"credentials": [
"consent"
],
"locale": "en"
},
"requestState": "q/tRS4BFAdaimSBhq"
}
}
Exemplo de Resposta de Erro
O exemplo a seguir mostra o conteúdo da resposta no formato JSON quando o Horário de Uso da configuração regional do usuário não é adicionado:
{
"status": "failed",
"ecId": "Q0ApB1Y1000000000",
"cause": [
{
"message": "Terms of Use Statement for locale fr isn't added.",
"code": "AUTH-3036"
}
]
}
}
Etapa 3: Fornecer o Consentimento de Horário de Uso
Nesse cenário, o usuário aceita ou rejeita os Termos de Uso do aplicativo. Se o usuário concordar com os Termos de Uso, o usuário será redirecionado para a página do aplicativo.
Se o usuário rejeitar os Termos de Uso, será exibida a resposta 401 com a mensagem de erro AUTH-3035 : É necessário aceitar os Termos de Uso para acessar este aplicativo.
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação no formato JSON quando o usuário concorda com o Horário de Uso.
{
"op": "acceptTOU",
"credentials": {
"consent": true
},
"requestState": "{{requestState}}"
}
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação no formato JSON quando o usuário rejeita o Horário de Uso.
{
"op": "acceptTOU",
"credentials": {
"consent": false
},
"requestState": "{{requestState}}"
}
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON quando o usuário concorda com a instrução TOU.
{
"authnToken": "eyJ4NXQjUzI1NiI6Iks0R0hvZVdoUm...YUAvuEOrERXrQRnjybdOkA2Q",
"status": "success",
"ecId": "Q0ApB1Y1000000000"
}
Exemplo de Resposta de Erro
O texto a seguir mostra o conteúdo da resposta no formato JSON quando o horário de uso é rejeitado pelo usuário.
{
"status": "failed",
"ecId": "Q0ApB1Y1000000000",
"cause": [
{
"message": "You must accept the Terms of Use to access this application.",
"code": "AUTH-3035"
}
]
}
Autenticando com Nome de Usuário e Senha e MFA e Retornando um OTP
Esse caso de uso fornece um exemplo passo a passo de uso da API REST de domínios de identidades para autenticação com credenciais de um usuário e Autenticação Multifator (MFA) e para retornar um OTP criptografado na resposta.
Use essa API de Autenticação somente se estiver criando sua própria experiência de log-in de ponta a ponta desenvolvendo um aplicativo de acesso personalizado para ser usado por domínios de identidades. Essa API de Autenticação não pode ser usada para integrar seus aplicativos a domínios de identidade para fins de sign-on único.
Faça download da coleção de exemplos de casos de uso de autenticação de domínios de identidades e do arquivo de variáveis globais da pasta idcs-authn-api-rest-clients no repositório GitHub de idm-samples e importe-os para o Postman.
Os domínios de identidades podem ser configurados para enviar um OTP (código de acesso único) baseado em tempo para diretamente a um usuário para autenticação ou ter o código de acesso criptografado e enviado ao cliente consumidor que pode enviá-lo ao usuário para autenticação.
Por exemplo, os administradores podem configurar domínios de identidade para enviar códigos de acesso únicos (OTP) baseados em tempo para o aplicativo Oracle Mobile Authenticator (OMA) ou enviar os OTPs por e-mail para o endereço de e-mail principal do usuário. Em ambos os casos, os domínios de identidade geram o OTP, o enviam diretamente ao usuário e o usuário insere o código para autenticação. Para entender como definir essas opções usando REST, consulte Inscrição do Fator de Autenticação com Verificação do Fator-SMS e Inscrição do Fator de Autenticação com Verificação do Fator-E-mail.
-
Etapa 1: Criar um Aplicativo CustomUI
-
Etapa 2: Gerar um Par de Chaves para um Certificado Autoassinados
-
Etapa 3: Configurar o Aplicativo para Retornar o OTP na Resposta
-
Etapa 4: Solicitar o OTP
Essas etapas pressupõem que a MFA esteja ativada e uma política de sign-on seja criada para a MFA. Consulte Configurando Definições de Autenticação Multifator.
Criptografia e decriptografia
Esta implementação usa a seguinte especificação para criptografar e decriptografar o código OTP recebido. Consulte PKCS #1: RSA Cryptography Specifications, Version 2.0, section 7.1 RSAES-OAEP.
Código de Decriptografia 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();
}
}
}
Etapa 1: Criar um Aplicativo CustomUI
Consulte Adicionar Aplicativos para obter mais informações sobre aplicativos personalizados.
Etapa 2: Gerar um Par de Chaves para um Certificado Autoassinados
- Certifique-se de que o arquivo de configuração
otp-client.confcontenha as seguintes informações. Em seguida, gere um par de chaves 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" -
Use o seguinte comando para gerar um certificado autoassinado.
#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
Etapa 3: Configurar o Aplicativo para Retornar o OTP na Resposta
- Na console do Identity Cloud Service, expanda a Gaveta de Navegação, selecione Aplicativos, aplicativo CustomUI, Configuração e Configuração do Cliente.
- Importe o certificado autoassinado no Certificado do Cliente Confiável e Salve a configuração.
Etapa 4: Solicitar o OTP
| Atributo | Valores Suportados/Valores de Amostra | Multivalor | Detalhes de Uso |
|---|---|---|---|
userFlowControlledByExternalClient
|
true / false | falso |
Definir esta opção como
e o OTP será retornado na resposta no formato criptografado especificado. Observação: o certificado usado para criptografia é submetido a upload para o aplicativo com antecedência e é referenciado usando o atributo |
| x5t | Miniatura do certificado SHA-1 da string/X509 |
Quando especificado, o serviço usa esse certificado submetido a upload para criptografar os dados OTP. Observação: O atributo "x5t" deve corresponder ao certificado submetido a upload. |
{
"op": "credSubmit",
"credentials": {
"username": "test.user",
"password": "example-password"
},
"userFlowControlledByExternalClient": true,
"x5t": "<certificate thumbprint>",
"requestState": "{{requestState}}"
}
| Atributo | Valores Suportados/Valores de Amostra | Multivalor | Detalhes de Uso |
|---|---|---|---|
otp
|
Mapear
|
falso |
Quando presente na resposta, o atributo contém o OTP criptografado com os seguintes detalhes.
|
Exemplo de Resposta
{
"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
}
}
Gerando Token de Acesso Usando API de Autenticação
Esse caso de uso fornece um exemplo passo a passo de como usar os domínios de identidade para gerar token de acesso usando a API de autenticação. O usuário obtém informações do usuário por meio do Token de Acesso Eu usando a API de Autenticação.
- Use essa API de Autenticação somente se estiver criando sua própria experiência de log-in de ponta a ponta desenvolvendo um aplicativo de acesso personalizado para ser usado por domínios de identidades.
- Essa API de Autenticação não pode ser usada para integrar seus aplicativos a domínios de identidade para fins de sign-on único.
Faça download da coleção de exemplos de casos de uso de autenticação de domínios de identidades e do arquivo de variáveis globais da pasta idcs-authn-api-rest-clients no repositório GitHub de idm-samples e importe-os para o Postman.
Quando o usuário tenta acessar um aplicativo associado ao Horário de Uso, o servidor de domínios de identidades usa o nome do aplicativo para extrair a política designada a esse aplicativo. Com base nas configurações do tenant, o servidor obtém o IDP e a política de autenticação e, em seguida, orienta o usuário para a próxima etapa.
Etapa 1: Iniciar o Fluxo de Autenticação
Obtenha o requestState inicial para iniciar o fluxo de autenticação.
Exemplo de Solicitação
O exemplo a seguir mostra a solicitação no 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}}
O
appName é opcional. O appName é o nome do Aplicativo que o cliente deseja acessar. Se um appName for fornecido, as políticas de sign-on específicas do Aplicativo serão processadas e o cliente será desafiado pelos fatores necessários com base nessa política.Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON:
{
"status": "success",
"ecId": "ecId",
"nextOp": [
"credSubmit"
],
"nextAuthFactors": [
"USERNAME_PASSWORD"
],
"USERNAME_PASSWORD": {
"credentials": [
"username",
"example-password"
]
},
"requestState": "{{requestState}}"
}
Na resposta, o valor nextOp indica o que pode ser enviado como o valor op na próxima solicitação. Neste exemplo de caso de uso, credSubmit deve ser enviado na próxima etapa. O requestState contém dados contextuais necessários para processar a solicitação.
Etapa 2: Enviar as Credenciais do Usuário
authnToken. Os itens a seguir devem ser incluídos na solicitação:credentials:nome de usuário e senharequestState:recebido na resposta da Etapa 1op:informa ao servidor que tipo de operação o cliente deseja
AuthnToken é o id_token no formato JWT que representa as informações atuais do usuário, a sessão e os dados da solicitação. Isso é usado para criar um cookie de sessão SSO e redirecionar para o URL de destino. Se o nome de usuário e a senha forem válidos, o AuthnToken será recuperado.
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON para o ponto final /sso/v1/sdk/authenticate:
{
"op":"credSubmit",
"credentials":{
"username":"admin@oracle.com",
"password":"example-password"
},
"requestState": "{{requestState}}"
}
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON em que o AuthnToken é recuperado:
{
"authnToken": "eyJ4NXQjUzI1NiI6Iks0R0hvZ...ZLjOZmKAvORB8OaV1Xqt1GL3tx1kyWA",
"status": "success",
"ecId": "5fR1O171000000000"
}
Etapa 3: Gerar Token de Acesso
Depois de recuperar um AuthnToken, ele será usado para obter o token de acesso do servidor OAuth.
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação no formato JSON:
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&scope=urn:opc:idm:__myscopes__&assertion={{authnToken}}
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON:
{
"access_token": "<redacted>",
"token_type": "Bearer",
"expires_in": 7600
}
Etapa 4: Obter Informações do Usuário
O usuário envia o token de acesso para obter suas informações, como nome de usuário, nome de exibição, id do e-mail etc.
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação no formato JSON.
{{HOST}}/admin/v1/Me
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON com informações do usuário.
{
"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"
]
}
Autenticando com Nome do Usuário, Senha e MFA
Esse caso de uso fornece um exemplo passo a passo de uso da API REST de domínios de identidades para autenticação com as credenciais de um usuário e a Autenticação Multifator (MFA).
- Use essa API de Autenticação somente se estiver criando sua própria experiência de log-in de ponta a ponta desenvolvendo um aplicativo de acesso personalizado para ser usado por domínios de identidades.
- Essa API de Autenticação não pode ser usada para integrar seus aplicativos a domínios de identidade para fins de sign-on único.
Faça download da coleção de exemplos de casos de uso de autenticação de domínios de identidades e do arquivo de variáveis globais da pasta idcs-authn-api-rest-clients no repositório GitHub de idm-samples e importe-os para o Postman.
Siga as etapas abaixo para este caso de uso:
Essas etapas pressupõem que a MFA esteja ativada e uma política de sign-on seja criada para a MFA. Consulte Configurando Definições de Autenticação Multifator.
Etapa 1: Iniciar o Fluxo de Autenticação
Obtenha o requestState inicial para iniciar o fluxo de autenticação.
Exemplo de Solicitação
O exemplo a seguir mostra a solicitação no 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}}
O
appName é opcional. O appName é o nome do Aplicativo que o cliente deseja acessar. Se um appName for fornecido, as políticas de sign-on específicas do Aplicativo serão processadas e o cliente será desafiado pelos fatores necessários com base nessa política.Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON:
{
"status": "success",
"ecId": "ecId",
"nextOp": [
"credSubmit"
],
"nextAuthFactors": [
"USERNAME_PASSWORD"
],
"USERNAME_PASSWORD": {
"credentials": [
"username",
"example-password"
]
},
"requestState": "{{requestState}}"
}
Na resposta, o valor nextOp indica o que pode ser enviado como o valor op na próxima solicitação. Neste exemplo de caso de uso, credSubmit deve ser enviado na próxima etapa. O requestState contém dados contextuais necessários para processar a solicitação.
Etapa 2: Enviar as Credenciais do Usuário
Submeta as credenciais do usuário como o primeiro fator, que são o nome de usuário e a senha. Para esta etapa, o cliente deve incluir os seguintes atributos:
-
credentials:nome de usuário e senha -
requestState:recebido na resposta da Etapa 1 -
op:informa ao servidor que tipo de operação o cliente deseja
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON:
{
"op": "credSubmit",
"credentials": {
"username": "{{username}}",
"password": "{{password}}"
},
"requestState": "{{requestState}}"
}
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON, pois o PUSH Notifications é o fator preferencial:
{
"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
}
}
Se a definição Dispositivo Confiável estiver desativada no nível do tenant, o atributo {{trustedDeviceSettings}} não será retornado na resposta.
{{trustedDeviceSettings}} será retornado, mas o valor {{trustDurationInDays}} será retornado como 0."trustedDeviceSettings": {
"trustDurationInDays": 0
}Na resposta, o status é pending, pois o usuário precisa Permitir ou Negar a Notificação PUSH em seu dispositivo. Os valores nextOp na resposta indicam o que pode ser enviado como o valor op na próxima solicitação. Neste exemplo de caso de uso, credSubmit é enviado na próxima etapa.
Etapa 3: Autenticar Usando o Fator Preferido
Autentique usando o fator preferencial, que neste exemplo de caso de uso é o PUSH Notifications. O cliente deve incluir os seguintes atributos nesta solicitação:
-
op:informa ao servidor que tipo de operação o cliente deseja -
requestState:recebido na resposta da Etapa 2
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON para concluir a autenticação usando o método preferencial:
{
"op":"credSubmit",
"requestState":"{{requestState}}"
}
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON:
{
"authnToken": "eyJraWQiOiJT.....kLbxxL97U_0Q",
"status": "success"
}
Autenticando com Nome de Usuário e Senha e Inscrevendo-se na MFA
Esse caso de uso fornece um exemplo passo a passo de uso da API de Autenticação de domínios de identidade para autenticação com as credenciais de um usuário e, em seguida, se inscrever na Autenticação Multifator (MFA).
- Use essa API de Autenticação somente se estiver criando sua própria experiência de log-in de ponta a ponta desenvolvendo um aplicativo de acesso personalizado para ser usado por domínios de identidades.
- Essa API de Autenticação não pode ser usada para integrar seus aplicativos a domínios de identidade para fins de sign-on único.
Faça download da coleção de exemplos de casos de uso de autenticação de domínios de identidades e do arquivo de variáveis globais da pasta idcs-authn-api-rest-clients no repositório GitHub de idm-samples e importe-os para o Postman.
Essas etapas pressupõem que a MFA esteja ativada e uma política de sign-on seja criada para a MFA. Consulte Configurando Definições de Autenticação Multifator.
Etapa 1: Iniciar o Fluxo de Autenticação
Obtenha o requestState inicial para iniciar o fluxo de autenticação.
Exemplo de Solicitação
O exemplo a seguir mostra a solicitação no 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}}
O
appName é opcional. O appName é o nome do Aplicativo que o cliente deseja acessar. Se um appName for fornecido, as políticas de sign-on específicas do Aplicativo serão processadas e o cliente será desafiado pelos fatores necessários com base nessa política.Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON:
{
"status": "success",
"ecId": "ecId",
"nextOp": [
"credSubmit"
],
"nextAuthFactors": [
"USERNAME_PASSWORD"
],
"USERNAME_PASSWORD": {
"credentials": [
"username",
"example-password"
]
},
"requestState": "{{requestState}}"
}
Na resposta, o valor nextOp indica o que pode ser enviado como o valor op na próxima solicitação. Neste exemplo de caso de uso, credSubmit deve ser enviado na próxima etapa. O requestState contém dados contextuais necessários para processar a solicitação.
Etapa 2: Enviar as Credenciais do Usuário
Submeta as credenciais do usuário como o primeiro fator, que são o nome de usuário e a senha. Para esta etapa, o cliente deve incluir os seguintes atributos:
-
credentials:nome de usuário e senha -
requestState:recebido na resposta da Etapa 1 -
op:informa ao servidor que tipo de operação o cliente deseja
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON:
{
"op": "credSubmit",
"credentials": {
"username": "{{username}}",
"password": "{{password}}"
},
"requestState": "{{requestState}}"
}
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no 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"
}
Neste exemplo de caso de uso, como a MFA é definida como opcional na Política de Sign-on (indicada por um valor de false para o atributo enrollmentRequired), o usuário tem a opção de se inscrever ou ignorar a inscrição. Se a MFA for necessária, o único valor nextOp será enrollment.
Neste exemplo de caso de uso, o enrollment é enviado na próxima etapa para iniciar a inscrição do fator MFA para o usuário. Observe que BYPASSCODE está ausente como um valor nextAuthFactors, pois o usuário não pode se inscrever usando um Código de Bypass. O Código de Bypass deve ser gerado pelo usuário usando Meu Perfil ou solicitando que um administrador gere um para eles.
Etapa 3: Iniciar Inscrição de Autenticação do Segundo Fator
-
op:informa ao servidor que tipo de operação o cliente deseja -
authFactor:define em qual fator de autenticação o usuário deseja se inscrever -
requestState:recebido na resposta da Etapa 2
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON:
{
"op":"enrollment",
"authFactor":"TOTP",
"requestState":"{{requestState}}"
}
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no 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 indicam o que pode ser enviado como o valor op na próxima solicitação. Neste exemplo de caso de uso, credSubmit é enviado na próxima etapa.O valor de
content sempre começa com oraclemobileauthenticator//.Etapa 4: Submeter Credenciais do Fator
requestState que foram recebidas na resposta da Etapa 3. Observe que o payload da solicitação não contém o atributo authFactor porque o requestState o contém. O cliente deve incluir os seguintes atributos:op:informa ao servidor que tipo de operação o cliente desejarequestState:recebido na resposta da Etapa 3
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON para enviar as credenciais de fator:
{
"op":"credSubmit",
"requestState":"{{requestState}}"
}
Exemplo de Resposta
O status success aparece na resposta quando a comunicação de canal traseiro do aplicativo OMA para o servidor é concluída e a verificação optCode é bem-sucedida. O exemplo a seguir mostra o conteúdo da resposta no formato JSON:
{
"status": "success",
"displayName": "Joe's iPhone",
"nextOp": [
"createToken",
"createSession",
"enrollment"
],
"requestState": "eyZa+10USFR7.....6I2vnfK82hnQ"
}
Na resposta, os valores nextOp indicam o que pode ser enviado como o valor op na próxima solicitação. Neste exemplo de caso de uso, createToken é enviado na próxima etapa.
Exemplo de Resposta Pendente
O status pending aparece quando a comunicação do canal traseiro do aplicativo OMA para o servidor não é concluída. O cliente continua sondando a cada 10 segundos e continua sondando por dois minutos. Após dois minutos, o servidor enviará o status de falha se a verificação otpCode não for bem-sucedida.
{
"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"
}
Etapa 5: Criar o Token de Autenticação
Esta etapa indica que o cliente é feito com todos os authnFactors e precisa de uma sessão criada. O servidor valida que nenhuma outra avaliação de fator (dependendo do que é definido para a política) é necessária e responde com o token ou nega acesso. O cliente deve incluir os seguintes atributos:
-
op:informa ao servidor que tipo de operação o cliente deseja -
requestState:recebido na resposta da Etapa 4
Exemplo de Solicitação
{
"op":"createToken",
"requestState":"{{requestState}}"
}Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON:
{
"authnToken": "{{authnToken}}",
"status": "success"
}
Autenticando Nome de Usuário e Senha e Inscrevendo-se na Recuperação de Conta
Esse caso de uso fornece um exemplo passo a passo de uso da API de Autenticação de domínios de identidades para autenticação com as credenciais de um usuário e, em seguida, inscrever-se na Recuperação de Conta.
- Use essa API de Autenticação somente se estiver criando sua própria experiência de log-in de ponta a ponta desenvolvendo um aplicativo de acesso personalizado para ser usado por domínios de identidades.
- Essa API de Autenticação não pode ser usada para integrar seus aplicativos a domínios de identidade para fins de sign-on único.
Faça download da coleção de exemplos de casos de uso de autenticação de domínios de identidades e do arquivo de variáveis globais da pasta idcs-authn-api-rest-clients no repositório GitHub de idm-samples e importe-os para o Postman.
Essas etapas pressupõem que vários fatores estejam ativados para Recuperação de Conta, mas a inscrição de MFA não está configurada. Consulte Configurar Recuperação de Conta e Configurar Definições de Autenticação Multifator.
Etapa 1: Iniciar o Fluxo de Autenticação
Obtenha o requestState inicial para iniciar o fluxo de autenticação.
Exemplo de Solicitação
O exemplo a seguir mostra a solicitação no 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}}
O
appName é opcional. O appName é o nome do Aplicativo que o cliente deseja acessar. Se um appName for fornecido, as políticas de sign-on específicas do Aplicativo serão processadas e o cliente será desafiado pelos fatores necessários com base nessa política.Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON:
{
"status": "success",
"ecId": "ecId",
"nextOp": [
"credSubmit"
],
"nextAuthFactors": [
"USERNAME_PASSWORD"
],
"USERNAME_PASSWORD": {
"credentials": [
"username",
"example-password"
]
},
"requestState": "{{requestState}}"
}
Na resposta, o valor nextOp indica o que pode ser enviado como o valor op na próxima solicitação. Neste exemplo de caso de uso, credSubmit deve ser enviado na próxima etapa. O requestState contém dados contextuais necessários para processar a solicitação.
Etapa 2: Enviar as Credenciais do Usuário
Submeta as credenciais do usuário como o primeiro fator, que são o nome de usuário e a senha. Para esta etapa, o cliente deve incluir os seguintes atributos:
-
credentials:nome de usuário e senha -
requestState:recebido na resposta da Etapa 1 -
op:informa ao servidor que tipo de operação o cliente deseja
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON:
{
"op": "credSubmit",
"credentials": {
"username": "{{username}}",
"password": "{{password}}"
},
"requestState": "{{requestState}}"
}
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no 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"
}
Neste exemplo de caso de uso, o usuário deve se inscrever na recuperação de conta (indicado por um valor de true para o atributo accRecEnrollmentRequired:true). O nextAuthFactors indica os fatores nos quais o usuário pode se inscrever para Recuperação de Conta.
Neste exemplo de caso de uso, a inscrição é enviada na próxima etapa para iniciar a inscrição de recuperação de conta para o usuário.
Etapa 3: Iniciar Inscrição de Recuperação de Conta
Esta etapa inicia a inscrição por SMS. O cliente deve incluir os seguintes atributos:
op: informa ao servidor que tipo de operação o cliente desejaauthFactor: define em qual fator de autenticação o usuário deseja se inscreverphoneNumber: define o número de telefone para o qual o texto SMS será enviadocountryCode: define o código do país do número de telefone para o qual o texto SMS será enviadorequestState: recebido na resposta da Etapa 2
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON:
{
"op":"enrollment",
"authFactor":"SMS",
"credentials":{
"phoneNumber":"1122334455",
"countryCode":"+44"
},
"requestState":"{{requestState}}"
}
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da solicitação no formato JSON:
{
"status": "success",
"ecId": "R^iCq19G000000000",
"displayName": "+44XXXXXXXX455",
"SMS": {
"credentials": [
"otpCode"
]
},
"nextOp": [
"credSubmit",
"resendCode",
"enrollment"
],
"requestState": "Y4sMHf7izgxcspF6zr...Y3GXLjjudeRMM2ZNty4E"
}
Na resposta, os valores nextOp indicam o que pode ser enviado como o valor de op na próxima solicitação. Neste exemplo de caso de uso, credSubmit é enviado na próxima etapa. O otpCode é enviado por SMS para o dispositivo do usuário.
Etapa 4: Submeter Credenciais do Fator
op: informa ao servidor que tipo de operação o cliente desejarequestState: recebido na resposta da Etapa 3
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON para enviar as credenciais de fator:
{
"op":"credSubmit",
"credentials":{
"otpCode":"974311"
},
"requestState":"{{requestState}}"
}
Exemplo de Resposta
O status de sucesso aparece na resposta quando a verificação optCode é bem-sucedida. O exemplo a seguir mostra o conteúdo da resposta no formato JSON:
{
"status": "success",
"ecId": "R^iCq1BG000000000",
"accRecEnrollmentRequired": false,
"displayName": "+44XXXXXXXX455",
"nextOp": [
"createToken",
"createSession",
"enrollment"
],
"requestState": "BKbGp43pwZad3zMSePWu7R47Va6myZdNY...vRVFN2FFQKIoDto"
}
Na resposta, o valor accRecEnrollmentRequired é definido como false, pois a inscrição na conta foi bem-sucedida. Os valores nextOp indicam o que pode ser enviado como o valor op na próxima solicitação. O valor nextOp "inscrição" permite que o usuário alterne para outro fator para se inscrever na recuperação da conta. Neste exemplo de caso de uso, createToken é enviado na próxima etapa.
Etapa 5: Criar o Token de Autenticação
op: informa ao servidor que tipo de operação o cliente deseja requestState: recebida na resposta da Etapa 4requestState: recebido na resposta da Etapa 4
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON:
{
"op":"createToken",
"requestState":"{{requestState}}"
}
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON:
{
"authnToken": "{{authnToken}}",
"status": "success",
"ecId": "R^iCq1FG000000000"
}
Autenticando Nome de Usuário e Senha e Inscrevendo-se na Recuperação de Conta e MFA
Esse caso de uso fornece um exemplo passo a passo de uso da API de Autenticação de domínios de identidade para autenticação com as credenciais de um usuário e, em seguida, inscrever-se para Recuperação de Conta e Autenticação Multifator (MFA).
- Use essa API de Autenticação somente se estiver criando sua própria experiência de log-in de ponta a ponta desenvolvendo um aplicativo de acesso personalizado para ser usado por domínios de identidades.
- Essa API de Autenticação não pode ser usada para integrar seus aplicativos a domínios de identidade para fins de sign-on único.
Faça download da coleção de exemplos de casos de uso de autenticação de domínios de identidades e do arquivo de variáveis globais da pasta idcs-authn-api-rest-clients no repositório GitHub de idm-samples e importe-os para o Postman.
- Etapa 1: Iniciar o Fluxo de Autenticação
- Etapa 2: Enviar as Credenciais do Usuário
- Etapa 3: Iniciar Inscrição de Recuperação de Conta
- Etapa 4: Submeter Credenciais do Fator
- Etapa 5: Criar o Token de Autenticação
- Etapa 6: Definir SMS como Fator de MFA Padrão na Sobreposição
- Etapa 7: Criar o Token de Autenticação
Essas etapas pressupõem que a Recuperação de Conta e a MFA estejam ativadas e uma política de sign-on seja criada para a MFA. Consulte Configurar Recuperação de Conta e Configurar Definições de Autenticação Multifator.
Etapa 1: Iniciar o Fluxo de Autenticação
Obtenha o requestState inicial para iniciar o fluxo de autenticação.
Exemplo de Solicitação
O exemplo a seguir mostra a solicitação no 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}}
O
appName é opcional. O appName é o nome do Aplicativo que o cliente deseja acessar. Se um appName for fornecido, as políticas de sign-on específicas do Aplicativo serão processadas e o cliente será desafiado pelos fatores necessários com base nessa política.Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no formato JSON:
{
"status": "success",
"ecId": "ecId",
"nextOp": [
"credSubmit"
],
"nextAuthFactors": [
"USERNAME_PASSWORD"
],
"USERNAME_PASSWORD": {
"credentials": [
"username",
"example-password"
]
},
"requestState": "{{requestState}}"
}
Na resposta, o valor nextOp indica o que pode ser enviado como o valor op na próxima solicitação. Neste exemplo de caso de uso, credSubmit deve ser enviado na próxima etapa. O requestState contém dados contextuais necessários para processar a solicitação.
Etapa 2: Enviar as Credenciais do Usuário
Submeta as credenciais do usuário como o primeiro fator, que são o nome de usuário e a senha. Para esta etapa, o cliente deve incluir os seguintes atributos:
-
credentials:nome de usuário e senha -
requestState:recebido na resposta da Etapa 1 -
op:informa ao servidor que tipo de operação o cliente deseja
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON:
{
"op": "credSubmit",
"credentials": {
"username": "{{username}}",
"password": "{{password}}"
},
"requestState": "{{requestState}}"
}
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no 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"
}
Neste exemplo de caso de uso, o usuário deve se inscrever na recuperação de conta (indicado por um valor de true para o atributo accRecEnrollmentRequired:true). O nextAuthFactors indica os fatores nos quais o usuário pode se inscrever para Recuperação de Conta.
Neste exemplo de caso de uso, a inscrição é enviada na próxima etapa para iniciar a inscrição de recuperação de conta para o usuário.
Etapa 3: Iniciar Inscrição de Recuperação de Conta
Esta etapa inicia a inscrição por SMS. O cliente deve incluir os seguintes atributos:
op: informa ao servidor que tipo de operação o cliente desejaauthFactor: define em qual fator de autenticação o usuário deseja se inscreverphoneNumber: define o número de telefone para o qual o texto SMS será enviadocountryCode: define o código do país do número de telefone para o qual o texto SMS será enviadorequestState: recebido na resposta da Etapa 2
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON:
{
"op":"enrollment",
"authFactor":"SMS",
"credentials":{
"phoneNumber":"1122334455",
"countryCode":"+44"
},
"requestState":"{{requestState}}"
}
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da solicitação no formato JSON:
{
"status": "success",
"ecId": "HI^kd1N0000000000",
"displayName": "+44XXXXXXXX213",
"SMS": {
"credentials": [
"otpCode"
]
},
"nextOp": [
"credSubmit",
"resendCode",
"enrollment"
],
"requestState": "FnwYT23S0qo+RHXN3Sx80D3....8CsoT3QezVbynT3LfZY3+sXN5E8OtEdM"
}
Na resposta, os valores nextOp indicam o que pode ser enviado como o valor de op na próxima solicitação. Neste exemplo de caso de uso, credSubmit é enviado na próxima etapa. O otpCode é enviado por SMS para o dispositivo do usuário. As credenciais informam ao usuário qual entrada é necessária para passar na próxima solicitação.
Etapa 4: Submeter Credenciais do Fator
requestState que foi recebido na resposta da Etapa 3. Observe que o payload da solicitação não contém o atributo authFactor porque o requestState o contém. O cliente deve incluir os seguintes atributos:op: informa ao servidor que tipo de operação o cliente desejarequestState: recebido na resposta da Etapa 3
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON para enviar as credenciais de fator:
{
"op":"credSubmit",
"credentials":{
"otpCode":"974311"
},
"requestState":"{{requestState}}"
}
Exemplo de Resposta
O status de sucesso aparece na resposta quando a verificação optCode é bem-sucedida. O exemplo a seguir mostra o conteúdo da resposta no 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"
}
Na resposta, o valor accRecEnrollmentRequired é definido como false, pois a inscrição na conta foi bem-sucedida. Os valores nextOp indicam o que pode ser enviado como o valor op na próxima solicitação. O valor nextOp "inscrição" permite que o usuário alterne para outro fator para se inscrever na recuperação da conta. Neste exemplo de caso de uso, createToken é enviado na próxima etapa.
Etapa 5: Criar o Token de Autenticação
op: informa ao servidor que tipo de operação o cliente deseja que requestState seja recebido na resposta da Etapa 4requestState: recebido na resposta da Etapa 4
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON:
{
"op":"createToken",
"requestState":"{{requestState}}"
}
Exemplo de Resposta
O exemplo a seguir mostra o conteúdo da resposta no 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"
}
Na resposta, como a MFA é necessária, enrollmentRequired tem um valor de true em mfaSettings. Como resultado, nenhum token é emitido. O EnrolledAccountRecoveryFactorsDetails mostra os fatores de recuperação de conta nos quais o usuário se inscreveu. Os valores nextOp indicam o que pode ser enviado como o valor op na próxima solicitação. Neste exemplo, o valor nextOp "enrollment" indica que o usuário deve se inscrever na MFA.
Etapa 6: Definir SMS como Fator de MFA Padrão na Sobreposição
Esta etapa indica que o cliente deve se inscrever na MFA.
O cliente deve incluir os seguintes atributos:
authFactor: indica em qual fator se inscrever para MFAaccountRecoveryFactor: quando definido como verdadeiro, indica que o usuário deseja reutilizar o fator de recuperação de conta já inscrito para MFA.
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON:
{
"op":"enrollment",
"authFactor": "SMS",
"credentials":{
"accountRecoveryFactor" : true
},
"requestState": "{{requestState}}"
}
Exemplo de Resposta
{
"status": "success",
"ecId": "HI^kd1R0000000000",
"nextOp": [
"createToken",
"createSession",
"enrollment"
],
"requestState": "7J6m/Z1PxXQZp4pigzt1F0CXp0kotX.....WXP2knQa16MNj5E8"
}
Na resposta, os valores nextOp indicam o que pode ser enviado como o valor de op na próxima solicitação. O valor nextOp "inscrição" permite que o usuário inscreva fator adicional para MFA. Neste exemplo de caso de uso, createToken é enviado na próxima etapa.
Etapa 7: Criar o Token de Autenticação
authnFactors e precisa de uma sessão criada. Dependendo do que for definido para a política, o servidor valida que nenhuma outra avaliação de fator é necessária e responde com o token ou nega acesso. O cliente deve incluir os seguintes atributos:op: informa ao servidor que tipo de operação o cliente desejarequestState: recebido na resposta da Etapa 6
Exemplo de Solicitação
O exemplo a seguir mostra o conteúdo da solicitação POST no formato JSON:
{
"op":"createToken",
"requestState":"{{requestState}}"
}
Exemplo de Resposta
{
"authnToken": "{{authnToken}}",
"status": "success",
"ecId": "HI^kd1W0000000000"
}Autenticando com Nome de Usuário e Senha e Mantenha-me Conectado
Ative e configure o recurso Keep me signed in (KMSI) para que os usuários possam acessar um domínio de identidades sem precisar acessar repetidamente.
Use as etapas a seguir para configurar o KMSI usando interfaces de aplicativo programáticas.
- Etapa 1: Ativar o KMSI para um Domínio de Identidades
- Etapa 2: Iniciar o Fluxo de Autenticação
- Etapa 3: Enviar as Credenciais do Usuário com o KMSI
- Etapa 4: Emitir Novamente authnToken Após a Expiração da Sessão
- Etapa 5: Enviar Credenciais do Usuário com o Fluxo KMSI e MFA
- Etapa 6: Emitir Novamente authnToken Após a Expiração da Sessão Quando um Fator MFA É Definido
Este tópico também contém as seguintes seções:
- kmsiToken Fluxo com requestState
- Alterações em /sso/v1/sdk/secure/session
- Assinatura de Payload para /autorizar Chamadas Iniciadas
Antes de Começar
- Certifique-se de que o KMSI tenha sido ativado para sua conta do Cloud. Você deve gerar uma solicitação de serviço (SR) com o Suporte da Oracle para ativar o KMSI. Especifique o seguinte nome de recurso na SR:
access.kmsi.support. Consulte Solicitações de Suporte. - Revise as seguintes seções neste tópico:
Etapa 1: Ativar o KMSI para um Domínio de Identidades
- Obtenha o token de acesso de administrador do domínio de identidades da sua conta.
- Execute
GETno ponto final/admin/v1/KmsiSettings/KmsiSettings. O sistema retorna oKmsiSettings. - Atualize os atributos necessários e execute
PUTno ponto final/admin/v1/KmsiSettings/KmsiSettings.
tokenValidityInDays- Informe quantos dias os usuários podem permanecer conectados antes de serem desconectados automaticamente.
kmsiEnabled- Indica se o KMSI está ativado para o domínio de identidades.
maxAllowedSessions- Informe o número máximo de sessões conectadas que um usuário pode ter.
Exemplo de Solicitação
{
"schemas": [
"urn:ietf:params:scim:schemas:oracle:idcs:KmsiSettings"
],
"tokenValidityInDays": 2160,
"kmsiEnabled": true,
"maxAllowedSessions": 5,
"id": "KmsiSettings"
}
Etapa 2: Iniciar o Fluxo de Autenticação
Obtenha o requestState inicial para iniciar o fluxo de autenticação.
Exemplo de Solicitação
O exemplo a seguir mostra a solicitação no 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}}
O
appName é opcional. O appName é o nome do Aplicativo que o cliente deseja acessar. Se um appName for fornecido, as políticas de sign-on específicas do Aplicativo serão processadas e o cliente será desafiado pelos fatores necessários com base nessa política.Exemplo de Resposta
{
"status": "success",
"ecId": "ZzK2c1^0000000000",
"nextOp": [
"credSubmit"
],
"nextAuthFactors": [
"USERNAME_PASSWORD"
],
"USERNAME_PASSWORD": {
"credentials": [
"username",
"password"
]
},
"keepMeSignedInEnabled": false,
"requestState": "FT7qI"
}
Observe o novo atributo keepMeSignedInEnabled incluído na resposta. Isso indica que esse domínio de identidades e aplicativo suportam KMSI. Se você tiver uma interface personalizada, use esse atributo para mostrar a opção Manter-me conectado na página de acesso.
Etapa 3: Enviar as Credenciais do Usuário com o KMSI
- Operação:
POST -
Ponto final:
/sso/v1/sdk/authenticate
Observe o novo atributo
keepMeSignedIn incluído na solicitação. Este atributo indica que o usuário deseja usar o KMSI.{
"op": "credSubmit",
"credentials": {
"username": "username",
"password": "Password"
},
"keepMeSignedIn": true,
"kmsiDeviceDisplayName": "Postman KeepMeSigned In",
"requestState": "requestState"
}
Se você tiver uma interface personalizada, use esse atributo para mostrar a opção KMSI, marque a caixa de seleção (ativada ou desativada) e envie esse parâmetro para criar a sessão KMSI.
Exemplo de Resposta
{
"authnToken": "QpfQIQ",
"kmsiToken": "ZJM",
"status": "success",
"ecId": "PR8Yf160000000000"
}
No exemplo de resposta, anote o atributo kmsiToken. Esse token pode ser usado para acessar qualquer aplicativo no futuro sem exigir que um usuário acesse novamente.
Etapa 4: Emitir Novamente authnToken Após a Expiração da Sessão
-
Operação:
POST -
Ponto final:
/sso/v1/sdk/authenticate
Exemplo de Solicitação
{
"op": "credSubmit",
"authFactor": "KMSI",
"appName": "AppName",
"kmsiToken": "{{kmsiToken}}"
}
Exemplo de Resposta
{
"authnToken": "QpfQIQ",
"kmsiToken": "ZJM",
"status": "success",
"ecId": "PR8Yf160000000000"
}
Observe a operação credSubmit com uma nova authFactor, appName e kmsiToken sendo enviada na solicitação. O SSO avalia a solicitação e retorna authnToken e o kmsiToken atualizado mais recente na resposta. Esse é um kmsiToken atualizado e substitui o token existente. Você deve incluir este kmsiToken atualizado na próxima solicitação.
Etapa 5: Enviar Credenciais do Usuário com o Fluxo KMSI e MFA
Inicie o GET em /sso/v1/sdk/authenticate na Etapa 2: Iniciar o Fluxo de Autenticação.
-
Operação:
POST -
Ponto final:
/sso/v1/sdk/authenticate
Exemplo de Resposta
{
"op": "credSubmit",
"credentials": {
"username": "username",
"password": "Password"
},
"keepMeSignedIn": true,
"kmsiDeviceDisplayName": "Postman KeepMeSigned In",
"requestState": "requestState"
}
Exemplo de Resposta
{
"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
}
}
Depois de obter o código de acesso único (OTP) no dispositivo, adicione o OTP na solicitação.
Exemplo de Solicitação
{
"op": "credSubmit",
"authFactor": "EMAIL-OTP/TOTP/SMS-OTP/PUSH/BYPASSCODE",
"credentials": {
"otpCode": "XXXX"
},
"requestState": "6tnX6Q4RGqe4Lq73WD0pQ"
}
A resposta inclui authToken e kmsiToken. Este é um kmsiToken atualizado.
Exemplo de Resposta
{
"authnToken": "QpfQIQ",
"kmsiToken": "ZJM",
"status": "success",
"ecId": "PR8Yf160000000000"
}
Etapa 6: Emitir Novamente authnToken Após a Expiração da Sessão Quando um Fator MFA É Definido
Quando um usuário tenta acessar usando kmsiToken e há um segundo fator configurado, o usuário sempre é solicitado a fazer a autenticação do segundo fator. Somente após a autenticação bem-sucedida, authnToken e kmsiToken serão enviados na resposta.
-
Operação:
POST -
Ponto final:
/sso/v1/sdk/authenticate
Exemplo de Solicitação
{
"op": "credSubmit",
"authFactor": "KMSI",
"appName": "AppName",
"kmsiToken": "{{kmsiToken}}"
}
A resposta contém um token KMSI atualizado e um desafio de MFA.
Exemplo de Resposta
{
"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 o mesmo processo em que o OTP será solicitado novamente no dispositivo. Forneça o payload abaixo com o OTP. A resposta deve incluir o authnToken.
Exemplo de Solicitação
{
"op": "credSubmit",
"authFactor": "EMAIL-OTP/TOTP/SMS-OTP/PUSH/BYPASSCODE",
"credentials": {
"otpCode": "XXXX"
},
"requestState": "6tnX6Q4RGqe4Lq73WD0pQ"
}
Exemplo de Resposta
{
"authnToken": "QpfQIQ",
"status": "success",
"ecId": "PR8Yf160000000000"
}
kmsiToken Fluxo com requestState
Use esse fluxo para suportar o contexto do browser quando você tiver o token KMSI, mas não o cookie KMSI. Após a expiração da sessão, o aplicativo faz uma chamada de autorização para o sistema de identidades com redirectUrl, state, nonce e assim por diante. Na resposta, o sistema de identidades retorna o requestState dentro do loginCtx. Esse requestState juntamente com o token KMSI é passado para redirecionar o aplicativo necessário após a extensão da sessão.
-
Operação:
POST -
Ponto final:
/sso/v1/sdk/authenticate
authFactor e autentica o KMSI com o parâmetro requestState. Isso permite que kmsiToken com requestState seja recuperado do loginCtx. Se
requestState e kmsiToken não forem do mesmo Aplicativo, a solicitação será recusada.Exemplo de Solicitação
{
"op": "credSubmit",
"authFactor": "KMSI",
"appName": "KMSIAdmin",
"kmsiToken": "{{kmsiToken}}",
"requestState": "{{requestState}}"
}
Exemplo de Resposta
{
"authnToken": "QpfQIQ",
"kmsiToken": "ZJM",
"status": "success",
"ecId": "PR8Yf160000000000"
}
Alterações em /sso/v1/sdk/secure/session
O KMSI requer que um novo atributo seja adicionado ao ponto final /sso/v1/sdk/secure/session. kmsiToken deve ser enviado ao ponto final pelo aplicativo de log-in personalizado.
| Exemplo de Solicitação | Exemplo de Resposta |
|---|---|
kmsiToken |
A nova variável de postagem de formulário kmsiToken, juntamente com authnToken ou requestState, redirecionará para o aplicativo juntamente com o cookie de sessão SSO e o cookie KMSI. |
Assinatura de Payload para Chamadas Iniciadas em /authorize
- Quando um usuário acessa qualquer aplicativo Web protegido por domínios de identidades, ele informa o URL do aplicativo, por exemplo,
https://example.com/home/pages/profile. - O sistema redireciona para a chamada
/authorizedo domínio de identidades. - O domínio de identidades redireciona o usuário para a página de acesso personalizado implantada pelo cliente.
- O aplicativo de acesso hospedado pelo cliente coleta os parâmetros de entrada e decodifica a entrada
loginCtx. - O parâmetro de entrada decriptografado corresponde à chamada
GET/sso/v1/sdk/authenticate. - O payload contém
keepMeSignedInEnabledpara identificar se o KMSI está ativado. - O aplicativo de log-in personalizado coleta as credenciais e as submete ao domínio de identidades.
- O domínio de identidades valida as credenciais e emite
kmsiTokeneauthnToken. - O aplicativo de log-in personalizado usa
authnTokenekmsiTokenao fazer chamada para o ponto final/sso/v1/sdk/secure/session. A nova sintaxe do ponto final seguro é descrita em Alterações no /sso/v1/sdk/secure/session. - O domínio de identidades valida o
authnToken,kmsiTokene, em seguida, o sistema de identidades emite o cookie de sessão SSO e o cookie KMSI. - Durante a sessão, o cookie KMSI é validado para estender a sessão sem reinserir as credenciais.