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.

Observação

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.
Observação

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.

A API de Autenticação pode:
  • 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.
Observaçã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.

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).

Nota

  • 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.
Dica

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. Cada etapa contém exemplos de solicitação e resposta:

Etapa 1: Iniciar o Fluxo de Autenticação

Um usuário abre uma janela do navegador para acessar uma página protegida.

Em segundo plano, a solicitação de autenticação é interceptada por domínios de identidade e redirecionada para o ponto final /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.
Observação

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>
O navegador recebe o código HTML, que contém JavaScript para enviar automaticamente o formulário para a página de acesso personalizada. Como o parâmetro 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"
    ]
  }
}
O parâmetro 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

O usuário seleciona o SAML externo IdP que deseja usar para autenticação na página de acesso personalizada exibida. A página de acesso personalizada deve construir e, em seguida, submeter as informações necessárias para o IdP selecionado como um FORM POST HTML para o ponto final /sso/v1/sdk/idp. Para esta etapa, os seguintes atributos devem ser incluídos:
  • requestState: recebido na resposta da Etapa 1
  • idpName: nome do IdP recebido na resposta da Etapa 1
  • idpType: tipo de IdP recebido na resposta da Etapa 1 (neste exemplo, é SAML)
  • idpId: id do IdP recebido na resposta da Etapa 1
  • appName: 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

O seguinte exemplo de JavaScript mostra como selecionar o 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.

Nota

  • 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.
Dica

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. Cada etapa contém exemplos de solicitação e resposta:

Etapa 1: Iniciar o Fluxo de Autenticação

Um usuário abre uma janela do navegador para acessar uma página protegida.

Em segundo plano, a solicitação de autenticação é interceptada por domínios de identidade e redirecionada para o ponto final /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.
Observação

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>
O navegador recebe o código HTML, que contém JavaScript para enviar automaticamente o formulário para a página de acesso personalizada. Como o parâmetro 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"
    ]
  }
}
O parâmetro 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 Social

O usuário seleciona o IdP social que deseja usar para autenticação na página de acesso personalizada exibida. A página de acesso personalizada deve construir e, em seguida, submeter as informações necessárias para o IdP selecionado como um FORM POST HTML para o ponto final /sso/v1/sdk/idp. Para esta etapa, os seguintes atributos devem ser incluídos:
  • requestState: recebido na resposta da Etapa 1
  • idpName: nome do IdP recebido na resposta da Etapa 1
  • idpType: tipo de IdP recebido na resposta da Etapa 1 (neste exemplo, é Social)
  • idpId: id do IdP recebido na resposta da Etapa 1
  • appName: 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 Social IdP

O exemplo JavaScript a seguir mostra como selecionar o IdP social:
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).

Nota

  • 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.
Dica

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. Cada etapa contém exemplos de solicitação e resposta:

Etapa 1: Iniciar o Fluxo de Autenticação

Um usuário abre uma janela do navegador para acessar uma página protegida.

Em segundo plano, a solicitação de autenticação é interceptada por domínios de identidade e redirecionada para o ponto final /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.
Observação

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>
O navegador recebe o código HTML, que contém JavaScript para enviar automaticamente o formulário para a página de acesso personalizada. Como o parâmetro 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"
    ]
  }
}
O parâmetro 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

O usuário seleciona o IdP externo que deseja usar para autenticação na página de acesso personalizada exibida. A página de acesso personalizada deve construir e, em seguida, submeter as informações necessárias para o IdP selecionado como um FORM POST HTML para o ponto final /sso/v1/sdk/idp. Para esta etapa, os seguintes atributos devem ser incluídos:
  • requestState: recebido na resposta da Etapa 1
  • idpName: nome do IdP recebido na resposta da Etapa 1
  • idpType: tipo de IdP recebido na resposta da Etapa 1 (neste exemplo, é SAML)
  • idpId: id do IdP recebido na resposta da Etapa 1
  • appName: 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

O seguinte exemplo de JavaScript mostra como 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
    }
}
O parâmetro 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.

Os seguintes atributos devem ser enviados na solicitação:
  • op: informa ao servidor que tipo de operação o cliente deseja
  • otpCode: o código enviado para o dispositivo do usuário
  • 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",
     "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.

Observação

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.
Observação

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.
Observação

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.

Para o ponto final /sso/v1/sdk/secure/session:
  • requestState: recebido na última resposta

    OU

  • authnToken: recebido na última resposta

    AND

  • 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>
OU
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.

Nota

  • 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.
Dica

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}}
Observação

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.

Nota

  • 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.
Dica

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}}
Observação

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)

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

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.

Nota

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.

Como alternativa, os administradores podem configurar domínios de identidade para retornar um OTP criptografado na resposta da API ao cliente de consumo para que o cliente de consumo possa iniciar ou enviar o OTP ao usuário. Duas vantagens para essa abordagem são que ela permite que o cliente consumidor personalize a mensagem de autenticação e também altere os detalhes do remetente para atender às suas necessidades de negócios. Para configurar domínios de identidade para retornar o OTP criptografado na resposta, o cliente consumidor deve concluir as etapas a seguir.
  1. Etapa 1: Criar um Aplicativo CustomUI

  2. Etapa 2: Gerar um Par de Chaves para um Certificado Autoassinados

  3. Etapa 3: Configurar o Aplicativo para Retornar o OTP na Resposta

  4. Etapa 4: Solicitar o OTP

Observação

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

Use o código Java a seguir para decriptografar o 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

Para receber o OTP na resposta, o cliente consumidor deve gerar um par de chaves privada/pública, depois gerar um certificado autoassinado e importar esse certificado para o aplicativo CustomUI.
  • Certifique-se de que o arquivo de configuração otp-client.conf contenha 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

Após a geração do certificado autoassinado, você precisará importá-lo para o aplicativo CustomUI.
  1. Na console do Identity Cloud Service, expanda a Gaveta de Navegação, selecione Aplicativos, aplicativo CustomUI, Configuração e Configuração do Cliente.
  2. Importe o certificado autoassinado no Certificado do Cliente Confiável e Salve a configuração.

Etapa 4: Solicitar o OTP

Payload de Solicitação
Atributo Valores Suportados/Valores de Amostra Multivalor Detalhes de Uso
userFlowControlledByExternalClient true / false falso
Definir esta opção como
true
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 no exemplo de solicitação, conforme mencionado abaixo.

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.

Exemplo de Solicitação
{
   "op": "credSubmit",
   "credentials": {
      "username": "test.user",
      "password": "example-password"
   },
   "userFlowControlledByExternalClient": true,
   "x5t": "<certificate thumbprint>",
   "requestState": "{{requestState}}"
}
Payload de Resposta
Atributo Valores Suportados/Valores de Amostra Multivalor Detalhes de Uso
otp

Mapear

"otp": {
        "value": "IMCw==",
        "alg": "RSAES-OAEP",
        "x5t": "<certificate thumbprint>"
 }
falso

Quando presente na resposta, o atributo contém o OTP criptografado com os seguintes detalhes.

  • value: Valor criptografado.
  • alg: Algoritmo usado para criptografia.
  • x5t: SHA-1 X509 Miniatura do certificado usado para criptografia.

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.

Nota

  • 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.
Dica

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}}
Observação

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

Nesse cenário, o usuário publica as credenciais do usuário e recupera o authnToken. Os itens a seguir devem ser incluídos na solicitação:
  • 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

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).

Nota

  • 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.
Dica

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:

Observação

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}}
Observação

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
    }
}
Nota

Se a definição Dispositivo Confiável estiver desativada no nível do tenant, o atributo {{trustedDeviceSettings}} não será retornado na resposta.

Se a definição Dispositivo Confiável estiver ativada no nível do tenant e se a regra da Regra de Sign-On correspondente tiver Frequência de MFA = Toda vez, o campo {{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).

Nota

  • 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.
Dica

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. Cada etapa contém exemplos de solicitação e resposta:
Observação

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}}
Observação

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

Esta etapa inicia a inscrição no Código de Acesso Único (TOTP) On-line Baseado em Tempo. O cliente deve incluir os seguintes atributos:
  • 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"
}
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, credSubmit é enviado na próxima etapa.
Observação

O valor de content sempre começa com oraclemobileauthenticator//.

Etapa 4: Submeter Credenciais do Fator

Esta etapa envia as credenciais de fator no 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 deseja

  • requestState: 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

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

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.

Nota

  • 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.
Dica

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.
Observação

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}}
Observação

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 deseja
  • authFactor: define em qual fator de autenticação o usuário deseja se inscrever
  • phoneNumber: define o número de telefone para o qual o texto SMS será enviado
  • countryCode: define o código do país do número de telefone para o qual o texto SMS será enviado
  • 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":"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

Esta etapa envia as credenciais de fator no 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 deseja
  • requestState: 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

Esta etapa indica que o cliente está pronto 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: recebida na resposta da Etapa 4
  • requestState: 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).

Nota

  • 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.
Dica

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.
Observaçã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}}
Observação

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 deseja
  • authFactor: define em qual fator de autenticação o usuário deseja se inscrever
  • phoneNumber: define o número de telefone para o qual o texto SMS será enviado
  • countryCode: define o código do país do número de telefone para o qual o texto SMS será enviado
  • 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":"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

Esta etapa envia as credenciais do fator junto com o 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 deseja
  • requestState: 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

Esta etapa indica que o cliente é feito com a inscrição de recuperação de conta 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 responde de acordo. O cliente deve incluir os seguintes atributos:
  • op: informa ao servidor que tipo de operação o cliente deseja que requestState seja recebido na resposta da Etapa 4
  • requestState: 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 MFA
  • accountRecoveryFactor: 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

Esta etapa indica que o cliente é feito com todos os 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 deseja
  • requestState: 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

O exemplo a seguir mostra o conteúdo da resposta no formato JSON:
{
    "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.

Este tópico também contém as seguintes seções:

Antes de Começar

Etapa 1: Ativar o KMSI para um Domínio de Identidades

Após o KMSI ter sido ativado para sua conta do Cloud, conclua as etapas a seguir para ativar o KMSI para um domínio de identidades do serviço IAM.
Nota

Se quiser usar a interface do usuário para ativar o KMSI, consulte Alterando Definições da Sessão e Criando uma Política de Sign-On.
  1. Obtenha o token de acesso de administrador do domínio de identidades da sua conta.
  2. Execute GET no ponto final /admin/v1/KmsiSettings/KmsiSettings. O sistema retorna o KmsiSettings.
  3. Atualize os atributos necessários e execute PUT no 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}}
Observação

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

Solicitação
  • Operação: POST
  • Ponto final: /sso/v1/sdk/authenticate

Exemplo de Solicitação
Observação

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

Solicitaçã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.

Solicitaçã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.

Solicitação
  • 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.

Solicitação
  • Operação: POST

  • Ponto final: /sso/v1/sdk/authenticate

A API suporta KMSI como authFactor e autentica o KMSI com o parâmetro requestState. Isso permite que kmsiToken com requestState seja recuperado do loginCtx.
Observação

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

authnToken ou requestState

authorization

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

  1. 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.
  2. O sistema redireciona para a chamada /authorize do domínio de identidades.
  3. O domínio de identidades redireciona o usuário para a página de acesso personalizado implantada pelo cliente.
  4. O aplicativo de acesso hospedado pelo cliente coleta os parâmetros de entrada e decodifica a entrada loginCtx.
  5. O parâmetro de entrada decriptografado corresponde à chamada GET /sso/v1/sdk/authenticate.
  6. O payload contém keepMeSignedInEnabled para identificar se o KMSI está ativado.
  7. O aplicativo de log-in personalizado coleta as credenciais e as submete ao domínio de identidades.
  8. O domínio de identidades valida as credenciais e emite kmsiToken e authnToken.
  9. O aplicativo de log-in personalizado usa authnToken e kmsiToken ao 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.
  10. O domínio de identidades valida o authnToken, kmsiToken e, em seguida, o sistema de identidades emite o cookie de sessão SSO e o cookie KMSI.
  11. Durante a sessão, o cookie KMSI é validado para estender a sessão sem reinserir as credenciais.