Este artigo documenta os testes de integração entre:

  • Auth0 como Authorization Server / Identity Provider
  • Node.js + Express, uma aplicação de exemplo, rodando em ambiente local, com suas APIs protegidas pelo Auth0
  • Oracle API Gateway expondo uma API pública do tipo Stock response protegida pelo Auth0
  • Oracle Integration Cloud (OIC) consumindo a API via REST Adapter

O objetivo foi validar o fluxo OAuth 2.0 Authorization Code, identificar os pontos de falha no cenário padrão do OIC, e demonstrar o cenário que funcionou utilizando o fluxo OAuth Custom Three Legged Flow.

Resultado Final

Resumo do que foi aprendido:

  1. O Auth0 consegue emitir tokens válidos para uma API customizada e também refresh_token, desde que a aplicação e a API estejam configuradas corretamente.
  2. A API Node pode validar o access_token com express-oauth2-jwt-bearer.
  3. O REST Adapter com OAuth Authorization Code Credentials pode falhar com Auth0 quando o fluxo exige parâmetros extras no /authorize, como audience, e quando o refresh token não está configurado do jeito esperado.
  4. O cenário que funcionou foi quando utilizamos o REST Adapter com OAuth Custom Three Legged Flow, porque ele permite controlar explicitamente:
    • o Authorization Request
    • o Access Token Request
    • o Refresh Token Request

Arquitetura do teste

Pré-requisitos

  • Tenant no Auth0
  • Instância do Oracle Integration Cloud
  • Node.js 18+
  • npm
  • curl
  • jq opcional para facilitar leitura de respostas JSON

Estrutura dos arquivos

.
├── README.md
├── examples
│   ├── curl
│   │   └── auth0-curl-examples.sh
│   ├── node
│   │   ├── buildEnvironment.sh
│   │   └── server.js
│   ├── oci
│   │   ├── api-gateway-auth0-echo.json
│   │   └── api-gateway-auth0-echo_consoleFormat.json
│   └── python
│       ├── callback.html
│       └── startLocalServer.sh
├── images
|
└── presentations
    └── auth0-api-gateway-jwks-flow.pptx

1. Configuração no Auth0

1.1 Criar a aplicação para proteção das APIs

No Auth0:

  1. Acesse Applications > Applications.
  2. Crie uma aplicação do tipo Regular Web Application.

3. Guarde as seguintes informações que estão na aba Settings:

  • Domain
  • Client ID
  • Client Secret

4. Em Allowed Callback URLs, adicione o callback do OIC e também uma URL para o seu ambiente local (faremos alguns testes em seguida):

https://<SEU_OIC>/icsapis/agent/oauth/callback
http://localhost:8081/callback.html

Atenção: Verifique a documentação do OIC para encontrar a URL de acordo com a versão do ambiente: Authenticate Requests for Invoking Oracle Integration Flows

  1. Em Advanced Settings > Grant Types, confirme que os grants abaixo estão habilitados:
    • authorization_code
    • refresh_token

1.2 Criar a API protegida

No Auth0:

  1. Acesse Applications > APIs.
  2. Crie uma API.
  3. Defina um Identifier, por exemplo:
https://lab-auth0-api

4. Na aba Settings, habilite Allow Offline Access para que o refresh_token funcione.

1.3 Configuração de Segurança entre Aplicação e API

No Auth0:

  1. Acesse Applications > Applications e selecione a aplicação que criamos.
  2. Na aba API Access, clique no botão Edit na API que criamos:

3. Clique no botão Grant Access:

1.4 Pontos importantes sobre o Auth0

Estes pontos foram relevantes no teste:

  • Para que o refresh_token funcione, precisamos incluir offline_access no escopo e o mesmo precisa estar habilitado no Auth0.
  • O request de autorização precisa considerar o audience (atributo Identifier da API criada no Auth0)
  • O Refresh Token Rotation ficou desativado durante os testes.

1.5 Links úteis do Auth0

2. API Node.js protegida por OAuth 2.0 para validarmos as Configurações

2.1 Criar o projeto

mkdir hello-oauth-api
cd hello-oauth-api
npm init -y
npm install express express-oauth2-jwt-bearer dotenv

2.2 Arquivo .env

Use o arquivo de exemplo em examples/node/.env.example.

Exemplo:

PORT=3000
AUTH0_DOMAIN=seu-tenant.us.auth0.com
AUTH0_AUDIENCE=https://lab-auth0-api

Crie o arquivo .env dentro da pasta hello-oauth-api ajustando o valor com o seu Domain do Auth0.

2.3 Código da API

O arquivo de exemplo está em examples/node/server.js. Copie o arquivo para a pasta hello-oauth-api

Essa API expõe:

  • GET /public sem autenticação
  • GET /hello protegido com bearer token

2.4 Executar localmente

node server.js

Teste da rota pública:

curl -i http://localhost:3000/public

3. Testes com curl no Auth0

Os comandos prontos estão em examples/curl/auth0-curl-examples.sh.

3.1 Variáveis de ambiente

export AUTH0_DOMAIN="SEU_TENANT.us.auth0.com"
export AUTH0_CLIENT_ID="SEU_CLIENT_ID"
export AUTH0_CLIENT_SECRET="SEU_CLIENT_SECRET"
export AUTH0_AUDIENCE="https://lab-auth0-api"
export REDIRECT_URI="http://localhost:8081/callback.html"

3.2 Obter o authorization code

Inicie um servidor http na sua máquina, apenas para log das informações:

python3 -m http.server 8081

Lembre-se de que configuramos uma URL de callback no Auth0, para o ambiente local.

Abra no navegador:

https://SEU_TENANT.us.auth0.com/authorize?response_type=code&client_id=SEU_CLIENT_ID&redirect_uri=http%3A%2F%2Flocalhost%3A8081%2Fcallback.html&scope=openid%20profile%20email%20offline_access&audience=https%3A%2F%2Flab-auth0-api

Essas informações precisam estar no padrão URL Encoded.

Depois do login, a URL de callback deve conter:

?code=SEU_AUTHORIZATION_CODE

Caso esteja utilizando o nosso exemplo:

3.3 Vamos utilizar o Authorization Code para obter o nosso Token

export AUTH_CODE="COLE_AQUI_O_CODE"

curl --request POST \
  --url "https://$AUTH0_DOMAIN/oauth/token" \
  --header "content-type: application/x-www-form-urlencoded" \
  --data "grant_type=authorization_code" \
  --data "client_id=$AUTH0_CLIENT_ID" \
  --data "client_secret=$AUTH0_CLIENT_SECRET" \
  --data "code=$AUTH_CODE" \
  --data "redirect_uri=$REDIRECT_URI"

3.4 Extrair e usar o access token

export ACCESS_TOKEN="$(curl --request POST \
  --url "https://$AUTH0_DOMAIN/oauth/token" \
  --header "content-type: application/x-www-form-urlencoded" \
  --data "grant_type=authorization_code" \
  --data "client_id=$AUTH0_CLIENT_ID" \
  --data "client_secret=$AUTH0_CLIENT_SECRET" \
  --data "code=$AUTH_CODE" \
  --data "redirect_uri=$REDIRECT_URI" | jq -r .access_token)"

Em caso de erro, solicite um novo Authorization Code, abrindo o seu navegador, conforme o passo 3.2.

3.5 Testar a API local com bearer token

curl -i http://localhost:3000/hello \
  -H "Authorization: Bearer $ACCESS_TOKEN"

Resposta esperada:

{"message":"hello world"}

3.6 Testar refresh token

export REFRESH_TOKEN="SEU_REFRESH_TOKEN"

curl --request POST \
  --url "https://$AUTH0_DOMAIN/oauth/token" \
  --header "content-type: application/x-www-form-urlencoded" \
  --data "grant_type=refresh_token" \
  --data "client_id=$AUTH0_CLIENT_ID" \
  --data "client_secret=$AUTH0_CLIENT_SECRET" \
  --data "refresh_token=$REFRESH_TOKEN" | jq

3.7 Problemas encontrados durante os Testes

Caso tenha encontrado o erro abaixo durante chamadas dos comandos curl:

{"error":"invalid_grant","error_description":"Invalid authorization code"}

Refaça a criação do authorization code abrindo o link novamente no seu navegador. Nesse processo é importante observar as seguintes informações:

  • o DOMAIN do ambiente Auth0;
  • o CLIENT_ID da aplicação criada no Auth0;
  • a URL de Callback que configuramos na aplicação do Auth0;
  • o atributo audience que utilizamos na criação da API no Auth0.

Agora, se o problema ocorreu durante a chamada da API, conforme abaixo:

InvalidTokenError: Invalid Compact JWS

Isso ocorreu quando o valor enviado no header Authorization não era um JWT válido para a biblioteca express-oauth2-jwt-bearer.

As causas mais prováveis foram:

  • envio do JSON inteiro da resposta do /oauth/token, e não apenas o access_token
  • access token sem audience informada
  • valor copiado com aspas, prefixos ou lixo no início/fim

Utilizar o comando “| jq” ao final dos comandos curl pode deixar mais legíveis as informações retornadas.

Checklist de validação:

echo "$ACCESS_TOKEN"

Um JWT válido deve ter o formato:

xxxxx.yyyyy.zzzzz

Para validar o seu token, você pode utilizar o site jwt.io. Atenção: Não coloque tokens reais em qualquer ferramenta pública.

4. OCI API Gateway com Auth0 validando JWT

Além do teste com a API Node, também é possível validar o token emitido pelo Auth0 diretamente no OCI API Gateway e criar uma rota simples de echo sem backend real.

Esse cenário é útil para:

  • validar rapidamente o token do Auth0 na OCI
  • testar o consumo pelo OIC sem depender de uma aplicação Node

4.1 Como funciona

O OCI API Gateway consegue validar o JWT utilizando as chaves públicas do Auth0.

Nesse modelo:

  1. o cliente obtém um JWT no Auth0
  2. o API Gateway busca as chaves públicas do tenant Auth0 via JWKS
  3. o gateway valida assinatura, iss e aud
  4. se o token for válido, responde à rota echo

4.2 Pré-requisitos específicos

No Auth0:

  1. a API precisa existir com um Identifier, por exemplo:
https://lab-auth0-api
  1. o token emitido precisa ser JWT e ter como aud o mesmo Identifier
  2. o tenant precisa expor o JWKS, no formato:
https://SEU_TENANT.us.auth0.com/.well-known/jwks.json

No OCI:

  1. criar um API Gateway
  2. criar um Deployment
  3. usar uma especificação com:
    • TOKEN_AUTHENTICATION
    • REMOTE_JWKS
    • issuers
    • audiences
    • STOCK_RESPONSE_BACKEND

Para mais detalhes de como criar um API Gateway, verifique esse link:

Para nosso exemplo, vamos criar o API Gateway em uma subnet pública.

4.3 Exemplo de deployment para o API Gateway

Vamos utilizar o arquivo api-gateway-auth0-echo.json para criar um deployment no API Gateway.

Substitua:

  • SEU_TENANT.us.auth0.com pelo domínio criado no Auth0.

Esse deployment criará:

  • autenticação via bearer token
  • validação JWT com JWKS do Auth0
  • rota GET /echo
  • resposta fixa em JSON

Vamos criar o deployment via oci cli:

  oci api-gateway deployment create \
  --compartment-id "<COMPARTMENT_OCID>" \
  --display-name "labAuth0" \
  --gateway-id "<GATEWAY_OCID>" \
  --path-prefix "/lab" \
  --specification file://./examples/oci/api-gateway-auth0-echo.json

Atenção: não se esqueça de ajustar os valores dos atributos compartment-id e gateway-id conforme o seu ambiente.

O arquivo api-gateway-auth0-echo.json foi gerado a partir do seguinte comando, via oci cli:

oci api-gateway deployment get \
  --deployment-id "<DEPLOYMENT_OCID>" \
  --query 'data.specification' \
  --output json > api-gateway-auth0-echo.json

Por isso, esse arquivo deve ser utilizado para a criação também via oci cli.

Há também o arquivo api-gateway-auth0-echo_consoleFormat.json, que foi gerado da seguinte forma:

oci raw-request --http-method GET \
  --target-uri 'https://apigateway.sa-saopaulo-1.oci.oraclecloud.com/20190501/deployments/<DEPLOYMENT_OCID>' \
  | jq .data.specification > api-gateway-auth0-echo_consoleFormat.json

Para saber o endpoint correto para a sua região do seu ambiente, consulte: API Gateway API

Com o arquivo api-gateway-auth0-echo_consoleFormat.json, é possível criar o deployment via console da OCI.

Atualize o seu arquivo, substituindo:

  • SEU_TENANT.us.auth0.com pelo domínio criado no Auth0.

Acesse o seu ambiente e navegue até Developer Services -> API Management -> Gateways. Selecione o seu API Gateway criado e entre na aba Deployments. Clique no botão Upload an existing deployment API e utilize o arquivo JSON específico para a console OCI.

Preencha as seguintes informações:

  • name = labAuth0;
  • Path prefix = /lab

Clique no botão Next:

Revise as informações:

  • Basic Info
  • Authentication
  • Routes

Clique no botão Create e aguarde até o seu deployment ficar com o Status = Active:

4.4 Testando sua API utilizando curl

Com um access_token válido emitido pelo Auth0 (todos os passos já citados anteriormente):

curl -i "https://SEU_GATEWAY/lab/echo" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

Se a validação passar, o retorno deve ser 200, com a seguinte resposta:

{"message" : "token validado pelo api gateway"}

Se o token estiver errado, o esperado é o erro 401 (Unauthorized).

5. Oracle Integration Cloud

5.1 REST Adapter

No REST Adapter, de acordo com a documentação, é possível consumir APIs REST protegidas por diversos fluxos de segurança. Para o nosso artigo, vamos utilizar estes:

  • OAuth Authorization Code Credentials (three-legged flow)
  • OAuth Custom Three Legged Flow

Acesse sua instância do OIC e crie um novo projeto, com o nome de lab-auth0:

Vamos criar uma conexão utilizando o REST Adapter, apenas para servir de Trigger para as integrações que criaremos em nossos exemplos, chamada de REST Template.

Criando a conexão:

Escolha REST Adapter:

Informe o nome da conexão e defina o atributo role:

Teste e salve sua conexão:

5.2 Integration

Vamos criar uma integração para os nossos testes, chamada INT001_LAB, com o seguinte formato:

  • GET /lab/{mensagem}
  • response JSON no formato abaixo:
{
  "retorno": "mensagem de retorno"
}

Essa integração apenas retornará na resposta o valor informado na requisição.

Informe o nome da Integração e depois clique no botão Create:

Vamos utilizar a conexão REST Template que criamos anteriormente para que ela seja a Trigger da nossa Integração. Clique no botão + e selecione a conexão:

Vamos configurar o que for solicitado em cada página:

Na página seguinte, em Configure Resource Configuration:

Atenção:

  • lab/{mensagem}, utilizado desta forma, o valor que está entre chaves se tornará o atributo que receberemos na requisição da integração;
  • habilite a opção “Configure this endpoint to receive the response”, porque essa integração terá uma mensagem de resposta.

Na página Configure Request Parameters, vamos manter como está:

Na página Configure Response, vamos definir o formato do retorno da integração e clicar em inline:

Agora nesta tela colamos o JSON de exemplo:

Vamos clicar no botão Continue, revisar as informações e depois em Finish, para concluirmos a configuração do Trigger da Integração.

Para concluirmos a integração:

  • mapear as informações de retorno utilizando o parâmetro de entrada;
  • definir business identifier.

Vamos mapear o retorno:

Temos que mapear desta forma e clicar no botão Validate:

Agora atualize o business identifier:

Mapeamos o atributo Mensagem como um business identifier:

Vamos salvar nossa integração. Ela não possui mais pendências ou problemas. Voltaremos para o projeto e vamos ativar a integração para testarmos se está tudo em ordem:

Nas configurações de ativação, selecione a opção Debug e depois o botão Activate:

Aguardamos alguns instantes, até que o status da integração esteja Active. Para testarmos a integração, selecionamos a opção Run:

Podemos verificar que tudo está funcionando:

Essa é uma forma de testar a integração criada utilizando a própria console da OCI.

5.3 Informações necessárias para nossos Testes

Para realizar nossos próximos testes e configurar outras conexões, precisaremos das seguintes informações do ambiente Auth0:

  • Client ID
  • Client Secret
  • Authorization Code URI = https://<tenant>.auth0.com/authorize
  • Access Token URI = https://<tenant>.auth0.com/oauth/token
  • Scope = openid profile email offline_access
  • Audience = https://lab-auth0-api (atributo Identifier da API que configuramos)

Como o fluxo de segurança Authorization Code funciona:

Imagem Auth0

Auth0 – How Authorization Code Flow works

5.4 OAuth Authorization Code Credentials (three-legged flow)

Vamos configurar uma nova conexão:

  • Utilize o Adapter REST;
  • Name: LAB-AUTHORIZATION_CODE
  • Identifier: LAB_AUTHORIZAT_CODE
  • Role: Invoke
    • Nosso objetivo com essa conexão é acionar a API que criamos no API Gateway

Na configuração de Properties:

  • Connection type: REST API Base URL
  • Connection URL: Endpoint do API Gateway

Na parte de Security:

Devemos clicar no botão Provide Consent, para estabelecer o fluxo de segurança entre o OIC x Auth0:

  • providencie os itens necessários para realizar a autenticação com o ambiente Auth0;
  • apenas como lembrete, para concluir esse procedimento, informamos a URL de Callback do OIC configurada na aplicação criada no Auth0.

Após concluído o processo de consentimento entre OIC x Auth0, teremos a seguinte mensagem de sucesso no procedimento:

Retornando para a tela de configuração da conexão, vamos clicar no botão Test para obter a mensagem de sucesso:

Salve sua conexão para finalizarmos o processo. Observe:

  • Configuration progress = 100%
  • Status da Conexão = CONFIGURED

Vamos voltar para a tela do projeto lab-auth0 no console do OIC, e clonar a integração INT001_LAB:

Informe a identificação da nova integração e depois clique no botão clone:

  • Name: INT002_LAB_AUTHORIZATION_CODE
  • Identifier: INT002

Com a nova integração gerada, vamos editar a mesma:

Dentro da integração, temos que adicionar a conexão LAB-AUTHORIZATION_CODE para invocar a API:

Configure Basic Info:

  • What is the endpoint’s relative resource URI? : /lab/echo
  • What action do you want to perform on the endpoint? : GET

Precisamos também selecionar a opção Configure this endpoint to receive the response e depois clicar no botão Continue:

Na parte de Configure Response, vamos clicar em inline:

Vamos utilizar esse JSON, que é justamente o response da API que criamos no API Gateway, e clicar no botão Continue:

{"message" : "token validado pelo api gateway"}

Após clicar novamente no botão Continue, revise as informações e clique em Finish:

Vamos editar o mapeamento da integração para que ela retorne o conteúdo da mensagem que está no API Gateway:

Neste mapeamento realizamos os seguintes passos:

  • Inserimos a Function -> String -> concat, para exibirmos uma única mensagem de retorno, juntando o que recebemos na integração e aquilo que é retornado pelo API Gateway;
  • Perceba que expandimos na parte de Sources e adicionamos o atributo Message na mensagem de retorno final da integração;
  • Não podemos esquecer de clicar em Validate para salvar o mapeamento, para depois voltarmos a tela principal e salvar a integração com essas mudanças.

Vamos ativar a integração, habilitar o modo Debug, aguardar sua ativação, e quando pronto, vamos testá-la.

O cenário falhou na renovação do token. O erro observado foi:

{
  "status":403,
  "message":"[DefaultAuthSecurityHandler] Could not refresh the access token. The access token response returned an unsuccessful status [403]. Error:{\"error\":\"invalid_grant\",\"error_description\":\"Unknown or invalid refresh token.\"}"
}

Vamos analisar a documentação:

The REST Adapter provides a security policy called the OAuth Authorization Code Credentials Flow. This policy provides a specific implementation of the OAuth as illustrated in the OAuth specification. For all other cases, OAuth Custom Three Legged Flow can be used to address these customizations.

Para resolvermos o refresh do token, vamos utilizar uma conexão customizada, que abordaremos no item a seguir.

5.5 OAuth Custom Three Legged Flow

Vamos configurar uma nova conexão:

  • Utilize o Adapter REST;
  • Name: LAB-THREE_LEGGED
  • Identifier: LAB_THREE_LEGGED
  • Role: Invoke
    • Nosso objetivo com essa conexão é acionar a API que criamos no API Gateway

Na configuração de Properties:

  • Connection type: REST API Base URL
  • Connection URL: Endpoint do API Gateway

Na parte de Security:

PropriedadeValorObservação
Security policyOAuth Custom Three Legged FlowOpção para customizarmos o fluxo OAuth 2.0
Authorization Requesthttps://yourDomain.us.auth0.com/authorize?response_type=code&client_id=xyz&redirect_uri=${redirect_uri}&scope=openid%20profile%20email%20offline_access&audience=https%3A%2F%2Flab-auth0-apiPerceba que as informações precisam estar no padrão URL Encoded
Access Token Request-X POST -H “Content-Type: application/x-www-form-urlencoded” -d “grant_type=authorization_code&client_id=xyz&client_secret=abc&code=${auth_code}&redirect_uri=${redirect_uri}” “https://yourDomain.us.auth0.com/oauth/token“Formato de comando curl para solicitar o Token

Observações Importantes:

  • ajuste as informações para utilizar o seu domínio Auth0;
  • informe seu Client ID e Client Secret da sua aplicação criada no Auth0;
  • ${redirect_uri} é uma variável de ambiente do OIC que possui a URL de callback. Ao invés de usarmos algo fixo, podemos utilizar essa anotação.
  • ${auth_code} variável de ambiente do OIC que possui o Authorization Code que retornou na primeira perna de autenticação.

Mais informações e detalhes consulte a documentação OAuth-Protected Patterns.

Vamos expandir a opção Optional security e configurar o atributo Refresh Token Request:

-X POST -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=refresh_token&client_id=xyz&client_secret=abc&refresh_token=${refresh_token}" "https://yourDomain.us.auth0.com/oauth/token"

Observações Importantes:

  • Aqui customizamos a forma de obter a renovação do token;
  • ajuste as informações para utilizar o seu domínio Auth0;
  • informe seu Client ID e Client Secret da sua aplicação criada no Auth0;
  • os demais atributos serão preenchidos automaticamente.

Devemos clicar no botão Provide Consent, para estabelecer o fluxo de segurança entre o OIC x Auth0:

  • providencie os itens necessários para realizar a autenticação com o ambiente Auth0;

Após concluído o processo de consentimento entre OIC x Auth0, teremos a seguinte mensagem de sucesso no procedimento:

Retornando para a tela de configuração da conexão, vamos clicar no botão Test para obter a mensagem de sucesso:

Salve sua conexão para finalizarmos o processo. Observe:

  • Configuration progress = 100%
  • Status da Conexão = CONFIGURED

Vamos voltar para a tela do projeto lab-auth0 no console do OIC, e clonar a integração INT002_LAB_AUTHORIZATION_CODE.

Informe a identificação da nova integração e depois clique no botão Clone:

  • Name: INT003_LAB_THREE_LEGGED
  • Identifier: INT003

Vamos selecionar a integração e clicar na opção Configure:

Vamos substituir a conexão LAB-AUTHORIZATION_CODE pela conexão LAB-THREE_LEGGED, utilizando a opção Replace:

Selecionar a conexão LAB-THREE_LEGGED e depois clicar no botão Save:

Atenção: Essa opção de substituir uma conexão por outra só é possível porque ambas são do tipo REST. Além disso, todo o mapeamento permanece o mesmo. Só estamos mudando a conexão para utilizar uma forma customizada de se obter a renovação do token e acionar a API que criamos no API Gateway.

Para ativar a integração, devemos ir para a próxima aba Activation. Selecionamos a integração, clicamos em Activate, utilizaremos o modo Debug.

Quando estiver ativa, vamos testá-la.

Podemos verificar que integração foi executada com sucesso:

Pela imagem confirmamos que a conexão utilizada foi a que configuramos e na resposta veio a mensagem do API Gateway.

6. Considerações

Neste artigo abordamos:

  • Auth0:
    • utilizar o mesmo como um Identity Provider;
    • configuramos fluxo OAuth 2.0 Authorization Code;
    • criamos um aplicativo e uma API;
  • node.js
    • criamos uma aplicação de exemplo, rodando localmente, protegida pelo Auth0;
    • realizamos testes para confirmar o funcionamento.
  • Oracle API Gateway
    • criamos um deploy de uma API REST com retorno fixo;
    • configuramos o API Gateway para utilizar o Auth0 como Identity Provider para validar o JWT gerado;
    • explicamos formas de realizar o deploy utilizando scripts.
  • OIC
    • mostramos como criar uma integração;
    • configuramos conexões REST com fluxo de Authorization Code e Custom Three Legged.

Espero que tenha conseguido transmitir as capacidades de cada componente, e principalmente como produtos de Low Code podem abstrair complexidades de configuração, agilizar o desenvolvimento e entregar segurança em todas suas etapas.

7. Referências

Github

Oracle

Auth0