Documentation Index

Fetch the complete documentation index at: https://docs.document360.com/llms.txt

Use this file to discover all available pages before exploring further.

Isenção de responsabilidade: Este artigo foi gerado usando tradução automática.

JWT

Prev Next

JSON Web Token (JWT) é um formato de token criptografado que transfere de forma segura dados de autenticação e autorização entre dois aplicativos. No Document360, o JWT é usado para autenticar logins de leitores no seu site de base de conhecimento.

O Document360 utiliza uma abordagem semelhante ao PKCE (Proof Key for Code Exchange, um método OAuth seguro) para gerar o token JWT.

Flowchart illustrating user login process for accessing knowledge base content securely.

Quando NÃO usar JWT

JWT não é a escolha certa se:

  • Sua organização já utiliza um Provedor de Identidade centralizado (Okta, Microsoft Entra, Google Workspace) e quer que os leitores se autentiquem por meio dele. Use SAML ou OpenID Connect em vez disso. Para isso, leia Single Sign-On (SSO).
  • Você precisa de recursos como leitores SSO de registro automático, auto-registro do leitor ou pular a página comum de login do Document360. Esses recursos não são suportados pelo JWT.
  • Você precisa da autenticação do usuário (portal). O JWT só suporta autenticação de leitores no site da base de conhecimento.

JWT vs SAML vs OpenID Connect

Característica JWT SAML / OpenID Connect
Gestão de leitores Os leitores são autenticados a partir do seu próprio aplicativo. Não é necessário criar ou gerenciar contas de leitor no Document360. Os leitores são gerenciados pelo Provedor de Identidade (IdP) da sua organização, como Okta, Azure AD ou Google Workspace.
Destino de login Sempre redireciona para o site da base de conhecimento. Os usuários não podem acessar o portal Document360 via JWT. Pode suportar logins tanto do leitor quanto da equipe, dependendo da configuração.
Quando usar Ideal se você não tem um IDP ou prefere gerenciar a autenticação na sua própria aplicação. Recomendado se sua organização já usa um IdP e quer autenticação centralizada e controle de acesso.
Fluxo de registro de usuários Você controla o login e o provisionamento de usuários no seu próprio app. Pode suportar auto-registro, redefinição de senha e gerenciamento do ciclo de vida do usuário, dependendo do IDP.
Página de login do SSO Você define a URL de Login e, opcionalmente, a URL de Logout nas configurações do JWT. A página de login é gerenciada pelo IDP, e os redirecionamentos são gerenciados por meio de configurações SAML ou OpenID.
Recursos avançados Não suportado: registro automático de leitores SSO, pular a página de login do Document360, auto-registro do leitor. Disponível dependendo das capacidades do IDP.
Implementação Configuração mais simples para desenvolvedores. Você gera o JWT, assina usando um cliente secreto criado no Document360 e gerencia a autenticação no seu app. Requer configuração de metadados IdP, certificados e mapeamentos com o Document360.

Como funciona a autenticação JWT

O diagrama abaixo mostra o fluxo completo de autenticação JWT entre sua aplicação, o servidor de identidade Document360 e o site da base de conhecimento.

Flowchart illustrating user authentication process with Document360 Identity Server and Customer App.

Terminologia chave

Mandato Descrição
Login URL Uma página pública de login no seu aplicativo onde os usuários são redirecionados para autenticar.
URL de geração de código Um endpoint backend seguro no seu app que envia dados do usuário para o Document360 para obter um código de autorização.
URL de retorno de chamada A URL no Document360 onde seu app redireciona o usuário após receber o código de autorização. Isso é gerado automaticamente pelo Document360.

Fluxo de autenticação

  1. O usuário acessa a base de conhecimento privada. O Document360 detecta que o SSO do JWT está ativado e redireciona o usuário para a URL de Login configurada nas configurações do JWT.
  2. O usuário faz login na sua aplicação. Se o usuário ainda não estiver autenticado, sua página de login cuida da autenticação dele.
  3. Seu backend solicita um código de autenticação único. Seu backend envia uma POST solicitação para a URL de geração de código com a identidade do usuário, opcional readerGroupIds, e tokenValidity em minutos. Essa solicitação deve ser autorizada usando HTTP Basic Auth com seu ID de Cliente e Secret do Cliente.

Cabeçalho de Autorização de Exemplo

Authorization: Basic Base64Encode(clientId:clientSecret)

Exemplo de Carga Útil JSON

{
  "username": "firstname + lastname",
  "firstName": "firstname",
  "lastName": "lastname",
  "emailId": "user email",
  "readerGroupIds": ["Obtain from Reader groups overview page in the Document360 portal (Optional)"],
  "tokenValidity": 15
}

NOTA

Garanta a sintaxe JSON correta para evitar erros de configuração.

  1. O servidor Document360 Identity retorna um código de autenticação. Se a solicitação for válida, o servidor de identidade do Document360 gera um código de autorização de uso único e o envia de volta para o seu backend.
  2. Seu app redireciona o usuário de volta para o Document360. Seu backend adiciona o código à URL de Callback e redireciona o usuário para ele. Por exemplo: https://yourproject.document360.io/jwt/authorize?code=xyz

NOTA

O código de autenticação é um código de uso único e não pode ser reutilizado.

  1. O Document360 valida o código. O Document360 envia para o servidor de identidade via backchannel para trocá-lo por um token JWT.
  2. A sessão de leitura é criada. O Document360 extrai informações do usuário e regras de acesso baseadas readerGroupIds no token. Uma sessão é criada para o leitor, concedendo-lhe acesso às categorias, idiomas ou versões permitidas.

Validade do token e comportamento de sessão

  • Você pode definir a duração da sessão usando o tokenValidity campo na carga útil (mínimo: 5 minutos, máximo: 1440 minutos).
  • Assim que o token expira, o leitor é redirecionado de volta para sua URL de login.
  • Se o usuário ainda estiver autenticado no seu app, um novo código é gerado e a sessão é restabeleceda de forma fluida.

Comece com o JWT

Artigo Descrição
Configure o JWT no Document360 Crie sua configuração no JWT, configure as configurações de login em nível de projeto e gere seus tokens secretos.
Implemente o JWT na sua aplicação Configure a lógica de redirecionamento do backend com exemplos de código em C#, Node.js e Java.
Teste sua configuração do JWT Verifique sua configuração usando cURL ou Postman antes de lançar.
Gerenciando configurações JWT Habilitar, desativar, excluir e gerenciar rotação de tokens, roteamento de domínio, estados da página de login e logs de auditoria.
Grupos de leitores do JWT Controle quais conteúdos os leitores podem acessar atribuindo-os a grupos de leitores via JWT.
Configure o JWT para o widget da base de conhecimento Configure a autenticação JWT para seu widget de base de conhecimento embarcada.
JWT para o chatbot de IA Proteja o acesso do seu chatbot de IA usando autenticação JWT.

DICHA

Se você está configurando o JWT pela primeira vez, complete os passos em ordem: Configure o JWT no Document360 → Implemente o JWT no seu aplicativo → Teste sua configuração do JWT.


FAQ

Se um usuário do JWT sai do aplicativo cliente, ele também está desconectado do Document360?

Não. A sessão no Document360 é independente após o login inicial. Os usuários podem continuar usando o Document360 até que a validade do token expire, mesmo após sair do aplicativo cliente. Por exemplo, se a validade do token for definida para 1 dia, a sessão do Document360 permanecerá ativa até que o token expire.

Posso fornecer um valor de validade de token fora do intervalo permitido?

Não. Se um valor fora da faixa for fornecido, o sistema atribui automaticamente o valor permitido mais próximo: 5 minutos para valores abaixo do mínimo e 1440 minutos para valores acima do máximo.

Qual é a diferença entre JWT e SSO?

Você pode ver uma comparação entre JWT (JSON Web Token) e SSO (Single Sign-On) na tabela abaixo:

Categoria JWT (JSON Web Token) SSO (Login Único)
Autenticação Tokens gerados por sessão ou solicitação do usuário. Autenticação centralizada entre aplicativos.
Vencimento do token Tokens normalmente expiram após um período determinado. Sem ficha; Sessão gerenciada pelo provedor de identidade.
Segurança Requer armazenamento seguro de tokens. Mais seguro; armazenamento centralizado de credenciais.
Uso Usado para autenticação sem estado, de uso único. Usado para múltiplas aplicações com um único login.
Integração Mais fácil de implementar em aplicativos personalizados. Requer integração com um provedor de identidade.

JWT e SSO (SAML ou OpenID Connect) podem estar ativos simultaneamente?

Sim. Configurações JWT e SSO podem coexistir no mesmo projeto sem conflito. Cada tipo é gerenciado de forma independente. Mudanças em um não afetam o outro.

O que devo fazer se fichas secretas forem perdidas?

Tokens secretos são exibidos apenas uma vez no momento da criação da configuração. Se for perdido, navegue até o modal Editar configuração e clique em Regenerar para o token relevante. A regeneração invalida imediatamente o token existente. Atualize sua aplicação com o novo token sem demora para evitar falhas de autenticação.