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.
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.
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
- 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.
- 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.
- Seu backend solicita um código de autenticação único. Seu backend envia uma
POSTsolicitação para a URL de geração de código com a identidade do usuário, opcionalreaderGroupIds, etokenValidityem 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
}
Garanta a sintaxe JSON correta para evitar erros de configuração.
- 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.
- 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
O código de autenticação é um código de uso único e não pode ser reutilizado.
- O Document360 valida o código. O Document360 envia para o servidor de identidade via backchannel para trocá-lo por um token JWT.
- A sessão de leitura é criada. O Document360 extrai informações do usuário e regras de acesso baseadas
readerGroupIdsno 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
tokenValiditycampo 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. |
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.