Autenticação de cliente no Jitterbit App Builder

O App Builder pode operar como um servidor de autorização OpenID Connect (OIDC). O servidor de autorização permite que aplicativos clientes, incluindo outras instâncias do App Builder, autentiquem usuários. O processo de login OIDC produz um token de acesso que permite ao aplicativo cliente acessar recursos protegidos em nome do usuário. Recursos protegidos incluem APIs REST e Webhook hospedadas no App Builder, bem como fontes de dados do App Builder Connector.

Suporte a protocolos

O protocolo OIDC é definido pelo padrão OpenID Connect Core 1.0. O OIDC é uma camada de identidade construída sobre a estrutura de autorização OAuth 2.0, que é definida pelo RFC-6749. Juntas, essas normas descrevem:

• Fluxos - Um fluxo é um processo pelo qual o cliente recupera tokens de identidade e de acesso. Por essa razão, os fluxos também são chamados de concessões.
• Endpoints - Cada fluxo envolve uma ou mais requisições HTTP para URLs bem conhecidas.
• Escopos - Aplicativos clientes podem solicitar um ou mais escopos. Os escopos determinam quais tokens são emitidos (identidade, atualização), o que está incluído nesses tokens (declarações) e quais APIs podem ser acessadas com esses tokens.
• Declarações - Conforme descrito pelo padrão, o token de identidade é fundamentalmente um JSON Web Token (JWT). Os JWTs são baseados em declarações. O escopo solicitado determina quais declarações estão incluídas no token de identidade.

Fluxos suportados

O servidor de autorização do App Builder suporta os seguintes fluxos básicos do OAuth 2.0:

• Código de Autorização. O fluxo de Código de Autorização permite que o cliente adquira um token de acesso, que permite ao cliente acessar recursos protegidos em nome do usuário. O fluxo de Código de Autorização é um fluxo interativo: um usuário deve estar presente para iniciar o fluxo de Código de Autorização.
• Credenciais do Cliente. O fluxo de Credenciais do Cliente permite que o aplicativo cliente adquira um token de acesso em nome de si mesmo. Este é um fluxo de servidor para servidor, operando tipicamente como uma conta de serviço.
• Token de Atualização. O fluxo de Token de Atualização permite que o cliente solicite um novo token de acesso uma vez que o token atual tenha expirado. Isso é às vezes referido como "acesso offline". O fluxo de token de atualização pode ser usado em combinação com os fluxos de Código de Autorização ou Credenciais do Cliente. O escopo offline_access habilita o fluxo de Token de Atualização (veja abaixo).

Conforme mencionado acima, OIDC é construído sobre a estrutura de autorização OAuth 2.0. OIDC aproveita os fluxos do OAuth 2.0, utilizando o parâmetro scope para optar por funcionalidades específicas do OIDC. O servidor de autorização do App Builder suporta os seguintes fluxos OIDC:

• Código de Autorização. Quando o escopo openid é especificado, o fluxo de Código de Autorização permite que o cliente autentique um usuário retornando um token de identidade adicional. Escopos adicionais determinam quais declarações estão incluídas no token.
• Token de Atualização. O fluxo de Token de Atualização opera da mesma forma no OIDC como no OAuth 2.0.

O servidor de autorização não suporta os fluxos OIDC Implícito ou Híbrido. O fluxo de Credenciais de Cliente do OAuth 2.0 não é um fluxo OIDC.

O fluxo de Código de Autorização pode ser usado com ou sem a extensão Proof Key for Code Exchange (PKCE), conforme definido pelo RFC-7636.

Endpoints suportados

O servidor de autorização do App Builder publica os seguintes endpoints:

Escopos suportados

O servidor de autorização do App Builder suporta os seguintes escopos:

Reivindicações suportadas

Conforme mencionado acima, o token de identidade é um token JWT baseado em reivindicações. O cliente pode determinar quais reivindicações estão incluídas no token de identidade especificando escopos.

Para uma descrição de cada uma dessas reivindicações, consulte a seção 5.1 Reivindicações Padrão do padrão OIDC. Qualquer reivindicação padrão não listada explicitamente acima não é suportada.

Configuração

Para utilizar o servidor de autorização, o administrador do App Builder deve primeiro:

1. Habilitar o servidor de autorização.
2. Registrar um aplicativo cliente.
3. Configurar o aplicativo cliente.

Habilitar o servidor de autorização

Para habilitar o servidor de autorização, comece fazendo login no App Builder como administrador:

1. Clique no link IDE.
2. Clique no botão Provedores de Segurança.
3. No painel Autenticação de Usuário, localize o provedor de segurança Servidor de Autorização e clique no ícone Detalhes (Chevron).
4. Clique no botão Editar.
5. Marque a opção Habilitado.
6. Clique no botão Salvar.

Registrar um aplicativo cliente

Cada aplicativo cliente que pretende autenticar usuários ou acessar recursos protegidos deve ser registrado. Para registrar um aplicativo cliente, comece fazendo login no App Builder como administrador e siga estas etapas:

1. Clique no link IDE.
2. Clique no botão Gerenciamento de Usuários.
3. Clique no botão Clientes.
4. Clique no botão +Cliente para registrar um novo aplicativo cliente.

5. Forneça o seguinte:

   • Nome: Um nome descritivo e amigável para o aplicativo cliente.
   • Descrição: Uma descrição opcional.
   • Usuário: Selecione a conta de usuário do serviço. Necessário para o fluxo de Credenciais do Cliente. Caso contrário, deixe em branco.
   • Provedor de Autenticação: Selecione um provedor ou deixe em branco.
   • Habilitado: Habilite ou desabilite o aplicativo cliente.

6. Clique no botão Salvar.

7. (Opcional) Clique em Mais, depois em Avançado. A caixa de diálogo Configurações Avançadas é aberta. Ela contém duas abas:

   • Propriedades: Defina as seguintes configurações, conforme necessário:

     • Requer PKCE: Quando selecionado, o cliente deve usar a extensão PKCE. Isso se aplica apenas ao fluxo de Código de Autorização e é necessário para clientes públicos.

     • Público: Quando selecionado, o cliente é público e segredos não podem ser armazenados de forma segura. Quando desmarcado, o cliente é confidencial e pode armazenar segredos de forma segura.

   • Durações do Token: Insira valores para os seguintes campos, conforme necessário:

     • Token de Acesso: Tempo de expiração do token de acesso, em minutos. Padrão: 60.

     • Token de Atualização: Tempo de expiração do token de atualização, em minutos. Padrão: 20160 (14 dias).

     • Token de Identidade: Tempo de expiração do token de identidade, em minutos. Padrão: 20.

     • Código de Autorização: Tempo de expiração do código de autorização, em minutos. Padrão: 5.

Gerar um segredo de cliente

O aplicativo cliente deve fornecer suas próprias credenciais ao solicitar um token de acesso. As credenciais do cliente consistem no ID do cliente e em um segredo do cliente. Segredos de cliente só podem ser gerados para clientes confidenciais. O painel de Segredos será ocultado para clientes públicos.

Para gerar um segredo de cliente:

1. No painel Segredos, clique no botão +Segredo.

2. Forneça o seguinte:

   • Descrição: Descrição opcional do segredo do cliente.
   • Expira Em: Se o segredo deve expirar, defina a data e hora de expiração. Caso contrário, deixe este campo em branco.

3. Clique no botão Salvar.

4. Copie o ID do Cliente e o Segredo do Cliente.

AVISO: Esta é a única vez que o segredo será visível.

Registrar URI de redirecionamento do cliente

Como mencionado acima, o fluxo de Código de Autorização é um fluxo interativo. Durante esse fluxo, o usuário é redirecionado para o endpoint de autorização. Assim que o usuário se autentica, ele é redirecionado de volta para o aplicativo cliente.

A URL de callback da aplicação cliente é referida como "redirect URI". Cada redirect URI deve ser registrada. As redirect URIs do cliente devem seguir as seguintes restrições:

• A URL de redirecionamento do cliente deve ser uma URL absoluta.
• A URL de redirecionamento do cliente deve usar o protocolo HTTPS. No entanto, a URL de redirecionamento do cliente pode usar o protocolo HTTP ao redirecionar para localhost.
• A URL de redirecionamento do cliente pode conter uma string de consulta.
• A URL de redirecionamento do cliente não deve conter um fragmento.

Para registrar uma redirect URI do cliente:

1. No painel Redirects, clique no botão +URL.
2. Forneça a URL.
3. Clique no botão Save.

Configurar a aplicação cliente

Qualquer aplicação cliente que seja compatível com os padrões OIDC ou OAuth 2.0 e que suporte os fluxos de Authorization Code ou Client Credentials pode utilizar o servidor de autorização do App Builder. Isso inclui o próprio App Builder: é possível configurar uma segunda instância do App Builder como um cliente.

Para configurar o cliente do App Builder, você precisará:

• URL raiz do servidor de autorização do App Builder, por exemplo, https://example.com/Vinyl.
• ID do cliente e segredo (veja acima)

Comece fazendo login na instância cliente do App Builder como administrador:

1. Clique no link IDE.
2. Clique no botão Security Providers.
3. No painel User Authentication, clique no botão +User Authentication.

4. Forneça o seguinte:

   • Name: Nome do provedor de segurança, por exemplo, App Builder.
   • Type: App Builder / OpenID Connect
   • Show On Login Form: Marque esta opção para exibir a opção de login no formulário de login.
   • User Provisioning: Marque esta opção para habilitar o provisionamento de usuários.

5. Clique no botão Save.

6. No painel Endpoints, clique no botão +Endpoint.

7. Forneça o seguinte:

   • Endpoint Type: OpenID Connect Issuer
   • URL: A URL raiz do servidor de autorização do App Builder.

8. Clique no botão Save.

9. No painel Credentials, clique no botão +Credential.

10. Forneça o seguinte:

    • Tipo: Cliente
    • Nome de Usuário: O ID do cliente (veja acima).
    • Senha: O segredo do cliente (veja acima).

11. Clique no botão Salvar.

12. No painel Provedor, clique no botão Editar.
13. Marque a opção Habilitado.
14. Clique no botão Salvar.

Uma vez concluído, os usuários poderão fazer login na instância do App Builder do cliente usando o servidor de autorização do App Builder.

Limitações conhecidas

O servidor de autorização do App Builder não suporta o seguinte

• Consentimento do usuário.
• Fluxos OIDC Implícito ou Híbrido