Adicionar autenticação ao seu aplicativo Nuxt 3

dica

A demonstração a seguir é construída no Nuxt 3.10.2.
O projeto de exemplo está disponível no repositório GitHub.
O Logto Nuxt SDK requer renderização do lado do servidor (SSR) para funcionar corretamente. Para aplicativos de página única (SPA), confira nosso Vue SDK.

Pré-requisitos

Uma conta Logto Cloud ou um Logto auto-hospedado.
Um aplicativo web tradicional Logto criado.

Instalação

Instale o Logto SDK através do seu gerenciador de pacotes favorito:

npm
pnpm
Yarn

npm i @logto/nuxt

pnpm add @logto/nuxt

yarn add @logto/nuxt

Integração

Registrar módulo Logto

No seu arquivo de configuração do Nuxt, adicione o módulo Logto e configure-o:

nuxt.config.ts
export default defineNuxtConfig({
  modules: ['@logto/nuxt'],
  runtimeConfig: {
    logto: {
      endpoint: '<your-logto-endpoint>',
      appId: '<your-logto-app-id>',
      appSecret: '<your-logto-app-secret>',
      cookieEncryptionKey: '<a-random-string>',
    },
  },
  // ...outras configurações
});

Como essas informações são sensíveis, é recomendável usar variáveis de ambiente (.env):

.env
NUXT_LOGTO_ENDPOINT="<your-logto-endpoint>"
NUXT_LOGTO_APP_ID="<your-logto-app-id>"
NUXT_LOGTO_APP_SECRET="<your-logto-app-secret>"
NUXT_LOGTO_COOKIE_ENCRYPTION_KEY="<a-random-string>"

Veja configuração em tempo de execução para mais informações.

Configurar URIs de redirecionamento

Antes de mergulharmos nos detalhes, aqui está uma visão geral rápida da experiência do usuário final. O processo de login pode ser simplificado da seguinte forma:

Seu aplicativo invoca o método de login.
O usuário é redirecionado para a página de login do Logto. Para aplicativos nativos, o navegador do sistema é aberto.
O usuário faz login e é redirecionado de volta para o seu aplicativo (configurado como o URI de redirecionamento).

Sobre o login baseado em redirecionamento

Este processo de autenticação segue o protocolo OpenID Connect (OIDC), e o Logto aplica medidas de segurança rigorosas para proteger o login do usuário.
Se você tiver vários aplicativos, pode usar o mesmo provedor de identidade (Logto). Uma vez que o usuário faz login em um aplicativo, o Logto completará automaticamente o processo de login quando o usuário acessar outro aplicativo.

Para saber mais sobre a lógica e os benefícios do login baseado em redirecionamento, veja Experiência de login do Logto explicada.

nota

Nos trechos de código a seguir, assumimos que seu aplicativo está sendo executado em http://localhost:3000/.

Configurar URIs de redirecionamento

Vá para a página de detalhes do aplicativo no Logto Console. Adicione um URI de redirecionamento http://localhost:3000/callback.

URI de redirecionamento no Logto Console

Assim como no login, os usuários devem ser redirecionados para o Logto para sair da sessão compartilhada. Uma vez concluído, seria ótimo redirecionar o usuário de volta para o seu site. Por exemplo, adicione http://localhost:3000/ como a seção de URI de redirecionamento pós logout.

Em seguida, clique em "Salvar" para salvar as alterações.

Manipular callback

Não é necessário configuração adicional para manipular a rota de callback. Ao registrar o módulo @logto/nuxt, ele fará o seguinte:

Adiciona três rotas para login (/sign-in), logout (/sign-out) e callback (/callback).
Importa dois composables: useLogtoClient e useLogtoUser.

Essas rotas são configuráveis via logto.pathnames nas opções do módulo, por exemplo:

nuxt.config.ts
export default defineNuxtConfig({
  logto: {
    pathnames: {
      signIn: '/login',
      signOut: '/logout',
      callback: '/auth/callback',
    },
  },
  // ...outras configurações
});

Confira o arquivo de definição de tipos no pacote @logto/nuxt para mais informações.

nota

Se você configurar a rota de callback para um caminho diferente, precisará atualizar o URI de redirecionamento no Logto de acordo.

Como as páginas Nuxt serão hidratadas e se tornarão um aplicativo de página única (SPA) após o carregamento inicial, precisamos redirecionar o usuário para a rota de login ou logout quando necessário. Para ajudar com isso, nosso SDK fornece o composable useLogtoUser(), que pode ser usado tanto no lado do servidor quanto no lado do cliente.

index.vue
<script setup lang="ts">
  import { useLogtoUser } from '#imports'; // Adicione esta linha se a importação automática estiver desativada
  const user = useLogtoUser();
</script>
<template>
  <!-- Botão simplificado para login e logout -->
  <nuxt-link :to="`/sign-${ user ? 'out' : 'in' }`"> Sign {{ user ? 'out' : 'in' }} </nuxt-link>
</template>

Ponto de verificação: Teste seu aplicativo

Agora, você pode testar seu aplicativo:

Execute seu aplicativo, você verá o botão de login.
Clique no botão de login, o SDK iniciará o processo de login e redirecionará você para a página de login do Logto.
Após fazer login, você será redirecionado de volta para o seu aplicativo e verá o botão de logout.
Clique no botão de logout para limpar o armazenamento local e sair.

Obter informações do usuário

Exibir informações do usuário

Quando o usuário está autenticado, o valor de retorno de useLogtoUser() será um objeto contendo as informações do usuário. Você pode exibir essas informações em seu aplicativo:

index.vue
<script setup lang="ts">
  const user = useLogtoUser();
</script>
<template>
  <!-- Exibir informações do usuário quando autenticado -->
  <ul v-if="Boolean(user)">
    <li v-for="(value, key) in user"><b>{{ key }}:</b> {{ value }}</li>
  </ul>
  <!-- Botão simplificado para login e logout -->
  <nuxt-link :to="`/sign-${ user ? 'out' : 'in' }`"> Sign {{ user ? 'out' : 'in' }} </nuxt-link>
</template>

Solicitar reivindicações adicionais

Você pode perceber que algumas informações do usuário estão faltando no objeto retornado de useLogtoUser(). Isso ocorre porque OAuth 2.0 e OpenID Connect (OIDC) são projetados para seguir o princípio do menor privilégio (PoLP), e o Logto é construído com base nesses padrões.

Por padrão, reivindicações limitadas são retornadas. Se você precisar de mais informações, pode solicitar escopos adicionais para acessar mais reivindicações.

info

Uma "reivindicação (Claim)" é uma afirmação feita sobre um sujeito; um "escopo (Scope)" é um grupo de reivindicações. No caso atual, uma reivindicação é uma informação sobre o usuário.

Aqui está um exemplo não normativo da relação escopo - reivindicação:

dica

A reivindicação "sub" significa "sujeito (Subject)", que é o identificador único do usuário (ou seja, ID do usuário).

O Logto SDK sempre solicitará três escopos: openid, profile e offline_access.

Para solicitar escopos adicionais, você pode configurar as opções do módulo logto:

nuxt.config.ts
import { UserScope } from '@logto/nuxt';

export default defineNuxtConfig({
  logto: {
    scopes: [UserScope.Email, UserScope.Phone], // Adicione mais escopos se necessário
    // ...outras configurações
  },
});

Então você pode acessar as reivindicações adicionais no objeto user:

index.vue
<template>
  <div v-if="user">
    <p>Nome: {{ user.name }}</p>
    <p>Email: {{ user.email }}</p>
    <p>Telefone: {{ user.phone }}</p>
  </div>
</template>

Reivindicações que precisam de solicitações de rede

Para evitar o inchaço do Token de ID (ID token), algumas reivindicações requerem solicitações de rede para serem buscadas. Por exemplo, a reivindicação custom_data não está incluída no objeto do usuário, mesmo que seja solicitada nos escopos. Para acessar essas reivindicações, você pode configurar a opção fetchUserInfo:

nuxt.config.ts
export default defineNuxtConfig({
logto: {
  scopes: [UserScope.CustomData],
  fetchUserInfo: true,
},
// ...outras configurações
});

Ao configurar fetchUserInfo, o SDK buscará as informações do usuário solicitando ao endpoint userinfo após o usuário fazer login, e user.custom_data estará disponível assim que a solicitação for concluída.

Obter informações do usuário manualmente

Para acessar todos os métodos fornecidos pelo cliente Logto, você pode usar o composable useLogtoClient():

index.vue
const client = useLogtoClient();

atenção

O cliente Logto está disponível apenas no lado do servidor. O composable retornará undefined no lado do cliente.

Você pode usar esses métodos do Logto para recuperar informações do usuário programaticamente:

client.getIdTokenClaims(): Obtenha informações do usuário decodificando o Token de ID (ID token) local. Algumas reivindicações (Claims) podem não estar disponíveis.
client.fetchUserInfo(): Obtenha informações do usuário enviando uma solicitação para o endpoint userinfo.

É importante notar que as reivindicações de informações do usuário que podem ser recuperadas dependem dos escopos (Scopes) usados pelo usuário durante o login, e considerando o desempenho e o tamanho dos dados, o Token de ID (ID token) pode não conter todas as reivindicações do usuário, algumas reivindicações do usuário estão disponíveis apenas no endpoint userinfo (veja a lista relacionada abaixo).

Por exemplo, para buscar manualmente informações do usuário:

index.vue
import { useLogtoClient, useState, callOnce } from '#imports';

const client = useLogtoClient();
const userInfo = useState(null);

// Chamar uma vez para evitar execução no lado do cliente
await callOnce(async () => {
  if (!client) {
    throw new Error('Cliente Logto não está disponível');
  }

  if (!(await client.isAuthenticated())) {
    return;
  }

  try {
    userInfo.value = await client.fetchUserInfo();
  } catch (error) {
    console.error('Falha ao obter informações do usuário:', error);
  }
});

Escopos e reivindicações

Logto usa as convenções de escopos e reivindicações do OIDC para definir os escopos e reivindicações para recuperar informações do usuário do Token de ID e do endpoint userinfo do OIDC. Tanto "escopo" quanto "reivindicação" são termos das especificações OAuth 2.0 e OpenID Connect (OIDC).

Aqui está a lista de Escopos (Scopes) suportados e as Reivindicações (Claims) correspondentes:

openid

Nome da Reivindicação	Tipo	Descrição	Precisa de userinfo?
sub	`string`	O identificador único do usuário	Não

profile

Nome da Reivindicação	Tipo	Descrição	Precisa de userinfo?
name	`string`	O nome completo do usuário	Não
username	`string`	O nome de usuário do usuário	Não
picture	`string`	URL da foto de perfil do Usuário Final. Este URL DEVE referir-se a um arquivo de imagem (por exemplo, um arquivo de imagem PNG, JPEG ou GIF), em vez de uma página da Web contendo uma imagem. Note que este URL DEVE referenciar especificamente uma foto de perfil do Usuário Final adequada para exibição ao descrever o Usuário Final, em vez de uma foto arbitrária tirada pelo Usuário Final.	Não
created_at	`number`	Hora em que o Usuário Final foi criado. O tempo é representado como o número de milissegundos desde a época Unix (1970-01-01T00:00:00Z).	Não
updated_at	`number`	Hora em que as informações do Usuário Final foram atualizadas pela última vez. O tempo é representado como o número de milissegundos desde a época Unix (1970-01-01T00:00:00Z).	Não

Outras reivindicações padrão incluem family_name, given_name, middle_name, nickname, preferred_username, profile, website, gender, birthdate, zoneinfo e locale também serão incluídas no escopo profile sem a necessidade de solicitar o endpoint userinfo. Uma diferença em relação às reivindicações acima é que essas reivindicações só serão retornadas quando seus valores não estiverem vazios, enquanto as reivindicações acima retornarão null se os valores estiverem vazios.

nota

Ao contrário das reivindicações padrão, as reivindicações created_at e updated_at estão usando milissegundos em vez de segundos.

email

Nome da Reivindicação	Tipo	Descrição	Precisa de userinfo?
email	`string`	O endereço de email do usuário	Não
email_verified	`boolean`	Se o endereço de email foi verificado	Não

phone

Nome da Reivindicação	Tipo	Descrição	Precisa de userinfo?
phone_number	`string`	O número de telefone do usuário	Não
phone_number_verified	`boolean`	Se o número de telefone foi verificado	Não

address

Por favor, consulte o OpenID Connect Core 1.0 para os detalhes da reivindicação de endereço.

custom_data

Nome da Reivindicação	Tipo	Descrição	Precisa de userinfo?
custom_data	`object`	Os dados personalizados do usuário	Sim

identities

Nome da Reivindicação	Tipo	Descrição	Precisa de userinfo?
identities	`object`	As identidades vinculadas do usuário	Sim
sso_identities	`array`	As identidades SSO vinculadas do usuário	Sim

urn:logto:scope:organizations

Nome da Reivindicação	Tipo	Descrição	Precisa de userinfo?
organizations	`string[]`	Os IDs das organizações às quais o usuário pertence	Não
organization_data	`object[]`	Os dados das organizações às quais o usuário pertence	Sim

urn:logto:scope:organization_roles

Nome da Reivindicação	Tipo	Descrição	Precisa de userinfo?
organization_roles	`string[]`	Os papéis da organização aos quais o usuário pertence com o formato `<organization_id>:<role_name>`	Não

Considerando o desempenho e o tamanho dos dados, se "Precisa de userinfo?" for "Sim", isso significa que a reivindicação não aparecerá no Token de ID, mas será retornada na resposta do endpoint userinfo.

Recursos de API e organizações

Recomendamos ler 🔐 Controle de Acesso Baseado em Papel (RBAC) primeiro para entender os conceitos básicos do RBAC do Logto e como configurar corretamente os recursos de API.

Configurar cliente Logto

Depois de configurar os recursos de API, você pode adicioná-los ao configurar o Logto em seu aplicativo:

nuxt.config.ts
export default defineNuxtConfig({
  logto: {
    resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'], // Adicionar recursos de API
    // ...other configs
  },
});

Cada recurso de API tem suas próprias permissões (escopos).

Por exemplo, o recurso https://shopping.your-app.com/api tem as permissões shopping:read e shopping:write, e o recurso https://store.your-app.com/api tem as permissões store:read e store:write.

Para solicitar essas permissões, você pode adicioná-las ao configurar o Logto em seu aplicativo:

nuxt.config.ts
export default defineNuxtConfig({
  logto: {
    scopes: ['shopping:read', 'shopping:write', 'store:read', 'store:write'],
    resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
    // ...other configs
  },
});

Você pode notar que os escopos são definidos separadamente dos recursos de API. Isso ocorre porque Resource Indicators for OAuth 2.0 especifica que os escopos finais para a solicitação serão o produto cartesiano de todos os escopos em todos os serviços de destino.

Assim, no caso acima, os escopos podem ser simplificados a partir da definição no Logto, ambos os recursos de API podem ter escopos read e write sem o prefixo. Então, na configuração do Logto:

nuxt.config.ts
export default defineNuxtConfig({
  logto: {
    scopes: ['read', 'write'],
    resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
    // ...other configs
  },
});

Para cada recurso de API, ele solicitará os escopos read e write.

nota

Não há problema em solicitar escopos que não estão definidos nos recursos de API. Por exemplo, você pode solicitar o escopo email mesmo que os recursos de API não tenham o escopo email disponível. Escopos indisponíveis serão ignorados com segurança.

Após o login bem-sucedido, o Logto emitirá os escopos apropriados para os recursos de API de acordo com os papéis do usuário.

Buscar token de acesso para o recurso de API

Para buscar o token de acesso para um recurso de API específico, você pode usar o método getAccessToken:

index.vue
<script setup lang="ts">
  // Um composable para acessar o cliente Logto
  const client = useLogtoClient();
  // Tornar o token disponível globalmente
  const accessToken = useState<string | undefined>('access-token');

  // Chamar uma vez no lado do servidor
  await callOnce(async () => {
    if (!client) {
      throw new Error('Cliente Logto não está disponível');
    }

    if (!(await client.isAuthenticated())) {
      return;
    }

    try {
      accessToken.value = await client.getAccessToken('https://shopping.your-app.com/api');
    } catch (error) {
      console.error('Falha ao obter token de acesso', error);
    }
  });
</script>

Este método retornará um token de acesso JWT que pode ser usado para acessar o recurso de API quando o usuário tiver as permissões relacionadas. Se o token de acesso em cache atual tiver expirado, este método tentará automaticamente usar um token de atualização para obter um novo token de acesso.

Buscar tokens de organização

Se organização é um conceito novo para você, por favor, leia 🏢 Organizações (Multi-tenancy) para começar.

Você precisa adicionar o escopo UserScope.Organizations ao configurar o cliente Logto:

nuxt.config.ts
import { UserScope } from '@logto/nuxt';

export default defineNuxtConfig({
  logto: {
    scopes: [UserScope.Organizations],
    // ...other configs
  },
});

Uma vez que o usuário esteja autenticado, você pode buscar o token de organização para o usuário:

index.vue
const token = await client.getOrganizationToken(organizationId);

Recursos de API da organização (Organization API resources)

Para obter um token de acesso para um recurso de API em uma organização, você pode usar o método getAccessToken com ambos o recurso de API e o ID da organização como parâmetros:

index.vue
const accessToken = await client.getAccessToken(
  'https://shopping.your-app.com/api',
  organizationId
);

Leituras adicionais

Fluxos do usuário final: fluxos de autenticação, fluxos de conta e fluxos de organização Configurar conectores Proteger sua API

Pré-requisitos​

Instalação​

Integração​

Registrar módulo Logto​

Configurar URIs de redirecionamento​

Configurar URIs de redirecionamento​

Manipular callback​

Implementar login e logout​

Ponto de verificação: Teste seu aplicativo​

Obter informações do usuário​

Exibir informações do usuário​

Solicitar reivindicações adicionais​

Reivindicações que precisam de solicitações de rede​

Obter informações do usuário manualmente​

Escopos e reivindicações​

Recursos de API e organizações​

Configurar cliente Logto​

Buscar token de acesso para o recurso de API​

Buscar tokens de organização​

Recursos de API da organização (Organization API resources)​

Leituras adicionais​

Pré-requisitos

Instalação

Integração

Registrar módulo Logto

Configurar URIs de redirecionamento

Configurar URIs de redirecionamento

Manipular callback

Implementar login e logout

Ponto de verificação: Teste seu aplicativo

Obter informações do usuário

Exibir informações do usuário

Solicitar reivindicações adicionais

Reivindicações que precisam de solicitações de rede

Obter informações do usuário manualmente

Escopos e reivindicações

Recursos de API e organizações

Configurar cliente Logto

Buscar token de acesso para o recurso de API

Buscar tokens de organização

Recursos de API da organização (Organization API resources)

Leituras adicionais