Estrutura de dados do aplicativo
Introdução
No Logto, um aplicativo refere-se a um programa de software ou serviço específico que está registrado na plataforma Logto e recebeu autorização para acessar informações do usuário ou realizar ações em nome de um usuário. Os aplicativos são usados para identificar a origem das solicitações feitas à API do Logto, bem como para gerenciar o processo de autenticação e autorização para usuários que acessam esses aplicativos.
O uso de aplicativos na experiência de login do Logto permite que os usuários acessem e gerenciem facilmente seus aplicativos autorizados a partir de um único local, com um processo de autenticação consistente e seguro. Isso ajuda a simplificar a experiência do usuário e garante que apenas pessoas autorizadas estejam acessando informações sensíveis ou realizando ações em nome da organização.
Os aplicativos também são usados nos logs de auditoria do Logto para rastrear a atividade do usuário e identificar possíveis ameaças ou violações de segurança. Ao associar ações específicas a um determinado aplicativo, o Logto pode fornecer insights detalhados sobre como os dados estão sendo acessados e utilizados, permitindo que as organizações gerenciem melhor seus requisitos de segurança e conformidade. Se você deseja integrar seu aplicativo ao Logto, veja Integrar Logto.
Propriedades
ID do aplicativo
O ID do aplicativo é uma chave única gerada automaticamente para identificar seu aplicativo no Logto, e é referenciado como client id no OAuth 2.0.
Tipos de aplicativo
Um aplicativo pode ser um dos seguintes tipos de aplicativo:
- Aplicativo nativo é um aplicativo que roda em um ambiente nativo. Ex.: aplicativo iOS, aplicativo Android.
- Aplicativo de fluxo de dispositivo é um tipo especial de aplicativo nativo para dispositivos com entrada limitada ou aplicativos sem interface (ex.: smart TVs, consoles de jogos, ferramentas CLI, dispositivos IoT). Ele utiliza o OAuth 2.0 Device Authorization Grant em vez do fluxo padrão baseado em redirecionamento. Veja Início rápido do fluxo de dispositivo para detalhes.
- Aplicativo de página única (SPA) é um aplicativo que roda em um navegador web, que atualiza a página com novos dados do servidor sem carregar páginas inteiras novas. Ex.: aplicativo React DOM, aplicativo Vue.
- Aplicativo web tradicional é um aplicativo que renderiza e atualiza páginas apenas pelo servidor web. Ex.: JSP, PHP.
- Aplicativo máquina para máquina (M2M) é um aplicativo que roda em um ambiente de máquina para comunicação direta entre serviços, sem interação do usuário.
Segredo do aplicativo
O segredo do aplicativo é uma chave usada para autenticar o aplicativo no sistema de autenticação, especificamente para clientes privados (aplicativos Web Tradicional e M2M) como uma barreira de segurança privada.
Aplicativos de Página Única (SPAs) e aplicativos Nativos não fornecem segredo do aplicativo. SPAs e aplicativos Nativos são "clientes públicos" e não podem manter segredos (o código do navegador ou os pacotes do aplicativo podem ser inspecionados). Em vez de um segredo do aplicativo, o Logto os protege com PKCE, validação rigorosa de URI de redirecionamento/CORS, tokens de acesso de curta duração e rotação de token de atualização.
Nome do aplicativo
O nome do aplicativo é um nome legível por humanos do aplicativo e será exibido no console de administração.
O nome do aplicativo é um componente importante para o gerenciamento de aplicativos no Logto, pois permite que os administradores identifiquem e acompanhem facilmente a atividade de aplicativos individuais dentro da plataforma.
É importante observar que o nome do aplicativo deve ser escolhido com cuidado, pois será visível para todos os usuários que têm acesso ao console de administração. Ele deve refletir com precisão o propósito e a função do aplicativo, além de ser fácil de entender e reconhecer.
Descrição
Uma breve descrição do aplicativo será exibida na página de detalhes do aplicativo no console de administração. A descrição tem como objetivo fornecer aos administradores informações adicionais sobre o aplicativo, como seu propósito, funcionalidade e outros detalhes relevantes.
URIs de redirecionamento
URIs de redirecionamento são uma lista de URIs de redirecionamento válidas que foram pré-configuradas para um aplicativo. Quando um usuário faz login no Logto e tenta acessar o aplicativo, ele é redirecionado para um dos URIs permitidos especificados nas configurações do aplicativo.
A lista de URIs permitidas é usada para validar o URI de redirecionamento incluído na solicitação de autorização enviada pelo aplicativo ao Logto durante o processo de autenticação. Se o URI de redirecionamento especificado na solicitação de autorização corresponder a um dos URIs permitidos nas configurações do aplicativo, o usuário será redirecionado para esse URI após a autenticação bem-sucedida. Se o URI de redirecionamento não estiver na lista permitida, o usuário não será redirecionado e o processo de autenticação falhará.
É importante garantir que todos os URIs de redirecionamento válidos sejam adicionados à lista permitida para um aplicativo no Logto, para garantir que os usuários possam acessar o aplicativo com sucesso após a autenticação.
Você pode conferir o Redirection endpoint para mais informações.
Entendendo URIs de redirecionamento em OIDC com Authorization Code Flow
Padrões curinga
Disponibilidade: Aplicativo de página única, Aplicativo web tradicional
URIs de redirecionamento suportam padrões curinga (*) para ambientes dinâmicos, como implantações de preview. Curingas podem ser usados nos componentes de hostname e pathname de URIs HTTP/HTTPS.
Regras:
- Curingas só são permitidos no hostname e pathname
- Curingas não são permitidos no esquema, porta, parâmetros de consulta ou fragmentos de hash
- Curingas no hostname devem incluir pelo menos um ponto (ex.:
https://*.example.com/callback)
Exemplos:
https://*.example.com/callback- corresponde a qualquer subdomíniohttps://preview-*.example.com/callback- corresponde a implantações de previewhttps://example.com/*/callback- corresponde a qualquer segmento de caminho
URIs de redirecionamento curinga não são padrão OIDC e podem aumentar a superfície de ataque. Use com cuidado e prefira URIs de redirecionamento exatos sempre que possível.
URIs de redirecionamento pós-logout
URIs de redirecionamento pós-logout são uma lista de URIs válidas que foram pré-configuradas para um aplicativo redirecionar o usuário após ele sair do Logto.
O uso de URIs de redirecionamento pós-logout permitidas para logout faz parte da especificação de Logout Iniciado pelo RP (Relying Party Initiated) no OIDC. Essa especificação fornece um método padronizado para aplicativos iniciarem uma solicitação de logout para um usuário, que inclui redirecionar o usuário para um endpoint pré-configurado após ele sair.
Quando um usuário faz logout do Logto, sua sessão é encerrada e ele é redirecionado para um dos URIs permitidos especificados nas configurações do aplicativo. Isso garante que o usuário seja direcionado apenas para endpoints autorizados e válidos após sair, ajudando a evitar acessos não autorizados e riscos de segurança associados ao redirecionamento de usuários para endpoints desconhecidos ou não verificados.
Você pode conferir o RP-initiated logout para mais informações.
Origens permitidas para CORS
As origens permitidas para CORS (Cross-origin resource sharing) são uma lista de origens permitidas a partir das quais um aplicativo pode fazer solicitações ao serviço Logto. Qualquer origem que não esteja incluída na lista permitida não poderá fazer solicitações ao serviço Logto.
A lista de origens permitidas para CORS é usada para restringir o acesso ao serviço Logto a partir de domínios não autorizados e para ajudar a prevenir ataques de falsificação de solicitação entre sites (CSRF). Ao especificar as origens permitidas para um aplicativo no Logto, o serviço pode garantir que apenas domínios autorizados possam fazer solicitações ao serviço.
A lista de origens permitidas deve conter a origem onde o aplicativo será servido. Isso garante que as solicitações do aplicativo sejam permitidas, enquanto solicitações de origens não autorizadas sejam bloqueadas.
Endpoint de configuração do provedor OpenID
O endpoint para OpenID Connect Discovery.
Endpoint de autorização
Endpoint de autorização é um termo OIDC, e é um endpoint obrigatório usado para iniciar o processo de autenticação de um usuário. Quando um usuário tenta acessar um recurso protegido ou aplicativo registrado na plataforma Logto, ele será redirecionado para o Endpoint de autorização para autenticar sua identidade e obter autorização para acessar o recurso solicitado.
Você pode conferir o Authorization Endpoint para mais informações.
Endpoint de token
Endpoint de token é um termo OIDC, é um endpoint de API web usado por um cliente OIDC para obter um token de acesso, um token de ID ou um token de atualização de um provedor OIDC.
Quando um cliente OIDC precisa obter um token de acesso ou token de ID, ele envia uma solicitação ao Endpoint de Token com uma concessão de autorização, que normalmente é um código de autorização ou um token de atualização. O Endpoint de Token então valida a concessão de autorização e emite um token de acesso ou token de ID para o cliente se a concessão for válida.
Você pode conferir o Token Endpoint para mais informações.
Endpoint Userinfo
O UserInfo Endpoint do OpenID Connect.
Sempre emitir token de atualização
Disponibilidade: Web tradicional, SPA
Quando ativado, o Logto sempre emitirá tokens de atualização, independentemente de prompt=consent estar presente na solicitação de autenticação, ou offline_access estar presente nos escopos.
No entanto, essa prática é desencorajada, a menos que seja necessário (geralmente é útil para algumas integrações OAuth de terceiros que exigem token de atualização), pois não é compatível com OpenID Connect e pode potencialmente causar problemas.
Rotacionar token de atualização
Padrão: true
Quando ativado, o Logto pode emitir um novo token de atualização quando um cliente usa um token de atualização para solicitar novos tokens. Se o token de atualização e sua concessão de aplicativo ainda forem válidos, a política padrão de rotação é:
- Tokens de atualização podem ser rotacionados apenas antes que a cadeia de tokens de atualização exista por um ano. Este é um limite interno de segurança de rotação; o próprio TTL do token de atualização ou o TTL da concessão do aplicativo podem expirar antes. Após atingir o limite, o Logto não rotaciona mais o token de atualização, e a expiração do token de atualização atual é final.
- Para clientes públicos que não usam tokens de atualização vinculados ao remetente (por exemplo, aplicativos Nativos regulares e aplicativos de página única), o Logto rotaciona o token de atualização em cada solicitação de token de atualização enquanto a rotação é permitida.
- Para outros clientes, o Logto rotaciona o token de atualização apenas quando ele está próximo da expiração (>=70% do Tempo de Vida (TTL) original já passou).
Para clientes públicos, é altamente recomendado manter a rotação de token de atualização ativada por motivos de segurança.
Tokens de atualização vinculados ao remetente são associados a uma chave de prova ou certificado mantido pelo cliente. Para SPAs regulares, a rotação emite um novo token de atualização, mas não estende o tempo de vida do token de atualização. O novo token de atualização herda o TTL restante do token de atualização anterior.
Tokens de atualização estão associados a uma concessão de aplicativo. O TTL padrão da concessão Logto é 180 dias. Quando a concessão expira, as solicitações de token de atualização falham e o token de atualização não pode mais ser usado para obter novos tokens, mesmo que a rotação de token de atualização esteja ativada.
Isso significa que o tempo de vida máximo prático de uma autorização baseada em token de atualização está atualmente limitado pelo TTL da concessão, revogação explícita ou pela própria expiração do token de atualização, o que ocorrer primeiro.
Entendendo a rotação de token de atualização
Tempo de vida (TTL) do token de atualização em dias
Disponibilidade: Aplicativo nativo, Web tradicional, SPA; Padrão: 14 dias; Máximo: 180 dias
A duração pela qual um token de atualização pode ser usado para solicitar novos tokens de acesso antes de expirar e se tornar inválido. As solicitações de token estenderão o TTL do token de atualização para esse valor.
Normalmente, um valor menor é preferido.
A atualização do TTL não está disponível em aplicativos de página única (SPAs) por motivos de segurança. Para SPAs, essa configuração controla o tempo de vida fixo do token de atualização a partir do momento da emissão original. O Logto não estenderá o TTL por meio de solicitações de token, e a rotação de token de atualização não impede que tokens de atualização de SPA expirem.
O TTL do token de atualização não é o único limite de expiração. Tokens de atualização estão vinculados a uma concessão de aplicativo, e o TTL padrão da concessão Logto é 180 dias. Quando a concessão expira, as solicitações de token de atualização falham mesmo que o token de atualização ainda esteja válido.
Para clientes onde as solicitações de token renovam o TTL do token de atualização, o TTL da concessão atua como o tempo de vida máximo absoluto para a cadeia de tokens de atualização. Para SPAs, o TTL fixo do token de atualização pode expirar antes da concessão.
Quando um token de atualização é emitido sem o escopo offline_access na solicitação de autorização, ele será vinculado à sessão do usuário. A sessão tem um TTL fixo de 14 dias. Após a expiração da sessão, o token de atualização se torna inválido independentemente da configuração de TTL do próprio token.
Para garantir que a configuração de TTL do token de atualização tenha efeito total, certifique-se de incluir o escopo offline_access em sua solicitação de autorização.
URI de logout backchannel
O endpoint de logout backchannel do OpenID Connect. Veja Logout federado: Logout back-channel para mais informações.
Máximo de concessões permitidas (maxAllowedGrants)
maxAllowedGrants é um campo opcional em nível de aplicativo em customClientMetadata que controla o número máximo de concessões ativas simultâneas por usuário para o aplicativo atual.
- Padrão:
undefined(sem limite) - Quando configurado: A cada autorização bem-sucedida, o Logto verifica o total de concessões ativas para o usuário no aplicativo atual (em todos os navegadores e dispositivos). Se o limite for excedido, o Logto revoga as concessões mais antigas.
Essa configuração é útil quando você deseja limitar dispositivos autenticados simultâneos por aplicativo.
Este campo não é suportado para:
- Aplicativos máquina para máquina
- Aplicativos protegidos
- Aplicativos SAML
Dados personalizados
Informações adicionais personalizadas do aplicativo não listadas nas propriedades predefinidas do aplicativo; os usuários podem definir seus próprios campos de dados personalizados de acordo com suas necessidades específicas, como configurações e definições específicas do negócio.