DEV Community

Quasar Framework Brasil profile image Tobias Mesquita
Tobias Mesquita for Quasar Framework Brasil

Posted on • Updated on

Protegendo uma aplicação com Refresh Tokens.

Índice

1 - Backend - Conhecendo o Backend

Voltar ao Topo

Antes de começamos a proteger a nossa aplicação, precisamos conhecer o Backend com o qual iremos conectar, assim como descobrir quais escolhas o mesmo adotou, uma vez que existe diferentes formas de criar e gerenciar os refresh tokens.

Para este artigo, estarei usando como base uma API feita com NestJS que usa um esquema de Refresh definido por mim, porém que cobre a maioria dos modelos e/ou estrategias de refresh token existentes.

O código fonte da API por ser encontrado no seguinte repositorio.:
https://github.com/TobyMosque/ws-auth-samples-backend/tree/refresh-after-spa

porém, não se preocupe com o código em si, mas com o comportamento da API, primeiro devemos analisar todos os endpoints utilizados para a autenticação.

Backend Methods

2 - Backend - Endpoint de Login

Voltar ao Topo

O primeiro endpoint que iremos visitar é o de login:

Endpoint Login

2.1 - Parâmetros do Login

Voltar ao Topo

Note que além do body com o username e o password, temos dois parâmetros que são passados na query string, estes parâmetros são utilizados para instruir o backend de como iremos gerenciar o refresh token.

rotation: valor boleano (true/false) que define se iremos usar rotação de tokens ou não

  • true: o refresh_token poderá ser usado apenas uma vez, então a cada /refresh a API irá retornar um novo refresh_token além de um access_token renovado.
  • false: o refresh_token poderá ser utilizado multiplas vezes.

flow: enumerador que define quem irá gerenciar o refresh_token

  • server: a API não irá devolver o refresh_token ao cliente, ficando a API responsável pela segurança do refresh_token, nesta caso o refresh_token é persistido em um cookie seguro.
  • client: a API irá devolver o refresh_token ao cliente, neste caso a API não irá persistir e/ou gerenciar o refresh_token, ficando a cargo do cliente a segurança do mesmo.

2.2 - Analisando o Login

Voltar ao Topo

Agora vamos fazer algumas chamadas a API para que possamos observar os diferentes comportamentos.

Lembrando que pode ser usada qual quer combinação de flow e rotation, porém irei utilizar apenas duas combinações nos exemplos.

2.2.1 - Primeiro Cenário - flow=server e rotation=false

Voltar ao Topo

Login com flow=server e rotation=false

Veja, que a API retornou a seguinte resposta:

{
  "accessToken": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIwMTgwY2E2My0yYjUyLTRlYjAtOTJlNi1mMWNlMzYxM2IxNjYiLCJuYW1lIjoiVG9iaWFzIE1lc3F1aXRhIiwiZW1haWwiOiJtZUB0b2JpYXNtZXNxdWl0YS5kZXYiLCJyb2xlcyI6WyJkZXZlbG9wZXIiLCJhZG1pbiIsInVzZXIiXSwiaWF0IjoxNjc4MDQ4NjQ0LCJleHAiOjE2NzgwNDg2NzQsImF1ZCI6Imh0dHBzOi8vand0LXNhbXBsZS50b2JpYXNtZXNxdWl0YS5kZXYiLCJpc3MiOiJodHRwczovL2p3dC1zYW1wbGUudG9iaWFzbWVzcXVpdGEuZGV2IiwianRpIjoiODBmMDQxMDctMGE4MS00ZWNhLWE1ODItNWM3NzViNDQ4MWJmIn0.GIAeo5sfrA5ksKp5msAJCAxLo4ivHxoHrTz6j9JBWyVgg3BmHN0veF24V27PG_K8yqjMiCKRONuNwkdZHENdQg"
}
Enter fullscreen mode Exit fullscreen mode

então, podemos fazer o decode do token em https://jwt.io

[{
  "alg": "HS512",
  "typ": "JWT"
}, {
  "sub": "0180ca63-2b52-4eb0-92e6-f1ce3613b166",
  "name": "Tobias Mesquita",
  "email": "me@tobiasmesquita.dev",
  "roles": [
    "developer",
    "admin",
    "user"
  ],
  "iat": 1678048644,
  "exp": 1678048674,
  "aud": "https://jwt-sample.tobiasmesquita.dev",
  "iss": "https://jwt-sample.tobiasmesquita.dev",
  "jti": "80f04107-0a81-4eca-a582-5c775b4481bf"
}]
Enter fullscreen mode Exit fullscreen mode

Se analisamos o iat e o exp, veremos que o token tem validade de 30 segundos, ou seja, se trata de um token de curta duração:

{
  iat: '05/03/2023 17:37:24'
  exp: '05/03/2023 17:37:54'
}
Enter fullscreen mode Exit fullscreen mode

Também podemos verificar que a API não retornou o refresh_token, porém o salvou como um cookie.

Set-Cookie: 
  REFRESH_TOKEN=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE2NzgwNDg2NDQsImV4cCI6MTY3ODEzNTA0NCwiYXVkIjoiaHR0cHM6Ly9qd3Qtc2FtcGxlLnRvYmlhc21lc3F1aXRhLmRldiIsImlzcyI6Imh0dHBzOi8vand0LXNhbXBsZS50b2JpYXNtZXNxdWl0YS5kZXYiLCJqdGkiOiI4MGYwNDEwNy0wYTgxLTRlY2EtYTU4Mi01Yzc3NWI0NDgxYmYifQ.GW3o37wLXY6eg4_ns9xuDKb8UOwlw1SF2CHdtWaXdXg;
  Path=api/auth/refresh; 
  Expires=Mon, 06 Mar 2023 20:37:24 GMT; 
  HttpOnly; 
  Secure; 
  SameSite=Lax
Enter fullscreen mode Exit fullscreen mode

E no caso desta API, o refresh_token também é token assinado, assim como o access_token, então também podemos fazer o decode do mesmo em https://jwt.io.

Apesar de termos usado um token assinado para o refresh_token, é bastante comum a utilização de objetos, sendo que estes objetos podem mudar drasticamente de uma API para outra, porém a finalidade e a utilização deles continua a mesma.

Segue um exemplo de refresh_token como objeto

{
  grant_type: 'refresh_token',
  refresh_token: `${refreshToken}`,
  client_id: `${clientId}`,
  client_secret: `${clientSecret}`,
  scope: '',
}

[{
  "alg": "HS256",
  "typ": "JWT"
}, {
  "iat": 1678048644,
  "exp": 1678135044,
  "aud": "https://jwt-sample.tobiasmesquita.dev",
  "iss": "https://jwt-sample.tobiasmesquita.dev",
  "jti": "80f04107-0a81-4eca-a582-5c775b4481bf"
}]
Enter fullscreen mode Exit fullscreen mode

E novamente poderemos analisar as datas de criação e expiração, e veremos que se trata de um token de longa duração, com validade de 24 horas:

{
  iat: '05/03/2023 17:37:24'
  exp: '06/03/2023 17:37:24'
}
Enter fullscreen mode Exit fullscreen mode

2.2.2 - Segundo Cenario - flow=client e rotation=true

Voltar ao Topo

Login com flow=client e rotation=true

Veja, que a API retornou a seguinte resposta:

{
  "accessToken": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIwMTgwY2E2My0yYjUyLTRlYjAtOTJlNi1mMWNlMzYxM2IxNjYiLCJuYW1lIjoiVG9iaWFzIE1lc3F1aXRhIiwiZW1haWwiOiJtZUB0b2JpYXNtZXNxdWl0YS5kZXYiLCJyb2xlcyI6WyJkZXZlbG9wZXIiLCJhZG1pbiIsInVzZXIiXSwiaWF0IjoxNjc4MDQ5MDcwLCJleHAiOjE2NzgwNDkxMDAsImF1ZCI6Imh0dHBzOi8vand0LXNhbXBsZS50b2JpYXNtZXNxdWl0YS5kZXYiLCJpc3MiOiJodHRwczovL2p3dC1zYW1wbGUudG9iaWFzbWVzcXVpdGEuZGV2IiwianRpIjoiMTViYzJlMjctMjkxYy00MzE5LTgxNWYtYTc1NDJkNWZmZTAyIn0.Xz--Ep6eTUGl_YG6VejwJFqaR-WKCPzFDywvT57KnU9eZ3lj9Con6GDZK5EEjFDTdBNvcfc3xsI5xtnuITLIOg",
  "refreshToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZWZyZXNoIjoiZjQzZmE0MDMtNTE3Yi00YmEzLTljNTktNDRjYzAxZGMzOWVjIiwiaWF0IjoxNjc4MDQ5MDcwLCJleHAiOjE2NzgxMzU0NzAsImF1ZCI6Imh0dHBzOi8vand0LXNhbXBsZS50b2JpYXNtZXNxdWl0YS5kZXYiLCJpc3MiOiJodHRwczovL2p3dC1zYW1wbGUudG9iaWFzbWVzcXVpdGEuZGV2IiwianRpIjoiMTViYzJlMjctMjkxYy00MzE5LTgxNWYtYTc1NDJkNWZmZTAyIn0.WtFmPuhQMrDvxkxoyc6rAFtr4wXErnMhnqRa4_VZ6Ts"
}
Enter fullscreen mode Exit fullscreen mode

Desta vez, a API retornou o refresh_token como parte da resposta (body) e não como um cookie, ficando a critério da API decidir qual é a melhor estratégia para proteger o refresh_token.

Como o access_token, terá o mesmo formato independente do flow e do rotation que forem passados, não é necessário decompor ele novamente, porém o refresh_token terá uma claim a mais.

[{
  "alg": "HS256",
  "typ": "JWT"
}, {
  "refresh": "f43fa403-517b-4ba3-9c59-44cc01dc39ec",
  "iat": 1678049070,
  "exp": 1678135470,
  "aud": "https://jwt-sample.tobiasmesquita.dev",
  "iss": "https://jwt-sample.tobiasmesquita.dev",
  "jti": "15bc2e27-291c-4319-815f-a7542d5ffe02"
}]
Enter fullscreen mode Exit fullscreen mode

A API irá utilizar a claim refresh para identificar que o refresh_token só pode ser utilizado uma vez, e se o mesmo já foi utilizado.

3 - Backend - Endpoint de Refresh

Voltar ao Topo

Agora que o login já foi bem dissecado, porém voltar a nossa atenção para o refresh

Endpoint de refresh

3.1 - Parâmetros do Refresh

Voltar ao Topo

Assim como no login, temos que passar alguns argumentos na query string, porém devemos passar apenas o flow, que deve ser igual ao que passamos durante o login.

flow: enumerador que define como o refresh_token será passado para a API.

  • server: a API escreveu um cookie, então a API deve ler deste cookie.
  • client: a aplicação Cliente deve passar o refresh_token no header RefreshToken.

3.2 - Analisando o Refresh

Voltar ao Topo

Agora, vamos dá continuidade aos cenários apresentados no login.

3.2.1 - Primeiro Cenário - flow=server e rotation=false

Voltar ao Topo

Refresh com flow=server e rotation=false

Neste caso, o refresh_token será lido do cookie, como não instruímos a API para utilizar o rotation do refresh_token, um novo refresh_token não foi gerado, e o cookie não será sobescrito.

3.2.2 - Segundo Cenário - flow=server e rotation=false

Voltar ao Topo

Refresh com flow=server e rotation=false

Neste exemplo, como o refresh_token foi criado usando o flow=client e o rotation=false, ele precisou ser enviado no header, assim como ele foi invalidado e um novo refresh_token, este estando disponível da resposta (body) da requisição feita à API.

Lembrando que, o token antigo foi invalidado, não podendo ser utilizado novamente.

4 - Backend - Endpoint de Logout

Voltar ao Topo

E por fim temos o endpoint /logout:

Endpoint de Logout

Neste caso só há uma coisa a ser dita, caso o flow=server, estamos instruindo a API a apagar o cookie gerenciado pela API.

Lembrando que o objeto desta API é disponibilizar a maior quantidade de fluxos e configurações possíveis, para que possamos aplicar os mesmos ao nosso frontend.

5 - Frontend - Entendendo as Vulnerabilidades

Voltar ao Topo

Quando falamos em proteger uma aplicação, temos de pensar nas principais vulnerabilidades que podem ocorrer ao se optar por utilizar tokens JWT para realizar a Autenticação e/ou Autorização.

Neste ponto, as duas principais vulnerabilidades são a XSS (Cross-Site Scripting) ou a CSRF (Cross-Site Request Forgery).

  • XSS: O ataque se dá pela injeção de um script que será capaz de ler o LocalStorage, SessionStorage, Cookies não seguros, ou qual quer outra informação que esteja disponível globalmente. Evitamos este problema ao não disponibilizar dados sensiveis globalmente.
  • CSRF: O cookie com o Token JWT é enviado para outro servidor, podendo assim ser lido por uma aplicação maliciosa. Evitamos este problema ao marcar o nosso cookie com HttpOnly; Secure; SameSite=Lax.

6 - Frontend - Protegendo um App SPA

Voltar ao Topo

Agora vamos falar sobre como proteger uma Aplicação SPA, porém isto também se aplica à aplicações PWA, Cordova, Capacitor e Electron. Ou seja, aplicações cujo o build possui apenas arquivos estáticos, não contando com a possibilidade de possuir um servidor/backend proprio.

Neste caso, para mantemos a aplicação segura, teremos de contar com uma API/Backend que disponibilize o flow=server ou o rotation=true.

6.1 - Realizando o Refresh

Voltar ao Topo

Mas vale ressaltar que independente do fluxo que iremos adotar, o boot do axios irá ser o mesmo, sendo que todos os ajustes serão feitos apenas no composable responsável pela autenticação.

No boot do Axios/API iremos injetar o Access Token no header e realizar o refresh caso o Access Token expire.

src/boot/axios.ts

import { boot } from 'quasar/wrappers';
import axios from 'axios';
import { InjectionKey } from 'vue';
import { useAuth } from 'src/composables/auth';

export const apiKey: InjectionKey<AxiosInstance> = Symbol('api-key');

export default boot(async ({ app, store, router }) => {
  const url = process.env.API_URL;
  const api = axios.create({ baseURL: url });

  const { token, refresh } = useAuth(api);

  api.interceptors.request.use(
    function (config) {
      if (token.value) {
        config.headers ||= {}
        config.headers.Authorization = `Bearer ${token.value}`;
      }
      return config;
    },
    function (error) {
      return Promise.reject(error);
    }
  );

  api.interceptors.response.use(
    function (response) {
      return response;
    },
    async function (error) {
      const res = error.response;
      switch (res.status) {
        case 401:
          if (token.value) {
            await refresh()
            if (token.value) {
              return api.request(error.config);
            }
          }
          break;
      }
      return Promise.reject(error);
    }
  );
  await refresh();
})
Enter fullscreen mode Exit fullscreen mode

Agora algumas explicações, como podemos ver nos destaques na imagem abaixo, o token é injetado no request, e caso haja um erro do tipo 401 no response, o refresh é acionado e a requisição é refeita.

Boot Axios - SPA

6.2 - Integrando a uma API com flow=server

Voltar ao Topo

Ao optamos por confiamos a segurança do Access Token à API, e caso a API persista o Refresh Token em um Cookie Seguro, a aplicação estará completamente imune a ataques do tipo XSS e/ou CSRF.

Agora irei mostrar um exemplo de implementação com o flow=server

src/composables/auth.ts

import { ref, computed } from 'vue'
import jwtDecode from 'jwt-decode';
import type { AxiosInstance } from 'axios'
import type { JwtPayload } from 'jwt-decode';

type Payload = JwtPayload & { roles: string[] }
interface LoginRequest {
  username: string;
  password: string;
}

const token = ref('')
function useAuth (api: AxiosInstance) {
  const payload = computed(() => {
    if (!token.value) {
      return null;
    }
    return jwtDecode(token.value) as Payload;
  })

  async function login (req: LoginRequest) {
    const { data } = await api.post('/auth/login?flow=server');
    token.value = data.accessToken;
  }
  async function refresh (req: LoginRequest) {
    try {
      const { data } = await api.get('/auth/refresh?flow=server');
      token.value = data.accessToken;
    } catch (error) {
      const res = error.response;
      if (res.status === 401) {
        token.value = '';
      }
    }
  }
  async function logout (req: LoginRequest) {
    await api.delete('/auth/logout?flow=server');
    token.value = '';
  }


  return {
    token,
    payload,
    login,
    refresh,
    logout
  }
}
Enter fullscreen mode Exit fullscreen mode

Note que no código acima estamos armazenando o token em memoria, assim como disponibilizamos os métodos de login, refresh e logout. Vale salientar que refresh_token não é accessível pelo frontend.

Integração com flow=server

6.3 - Integrando a uma API com rotation=true

Voltar ao Topo

No caso da API não se responsabilizar pelo Refresh Token, ou de termos algo que esteja a bloquear o Cookie Seguro da API, teremos de persistir o Refresh Token no Local Storage, o que irá abrir a nossa aplicação à um ataque do tipo XSS.

Para mitigamos este problema, devemos adotar o rotation=true, de forma que o token será invalidado a cada uso, ou seja, em 99% dos casos, o Refresh Token será invalidado junto ao Access Token, o que limita o Ataque do tipo XSS e qual quer dano que venha a ser gerado por ele.

Agora iremos abordar o fluxo com flow=client com rotation=true
src/composables/auth.ts

import { ref, computed } from 'vue'
import { useLocalStorage } from '@vueuse/core'
import jwtDecode from 'jwt-decode';
import type { AxiosInstance } from 'axios'
import type { JwtPayload } from 'jwt-decode';

type Payload = JwtPayload & { roles: string[] }
interface LoginRequest {
  username: string;
  password: string;
}

const token = ref('')
const refresh = useLocalStorage('refresh-token', '')
function useAuth (api: AxiosInstance) {
  async function login (req: LoginRequest) {
    const { data } = await api.post('/auth/login?flow=client&rotation=true');
    token.value = data.accessToken;
    refresh.value = data.refreshToken;
  }
  async function refresh (req: LoginRequest) {
    try {
      const { data } = await api.get('/auth/refresh?flow=client', {
        headers: {
          RefreshToken: refresh.value
        }
      });
      token.value = data.accessToken;
      refresh.value = data.refreshToken;
    } catch (error) {
      const res = error.response;
      if (res.status === 401) {
        token.value = '';
        refresh.value = '';
      }
    }
  }
  async function logout (req: LoginRequest) {
    await api.delete('/auth/logout?flow=client');
    token.value = '';
    refresh.value = '';
  }

  const payload = computed(() => {
    if (!token.value) {
      return null;
    }
    return jwtDecode(token.value) as Payload;
  })
  return {
    token,
    payload,
    login,
    refresh,
    logout
  }
}
Enter fullscreen mode Exit fullscreen mode

Neste caso, o refresh token é gerenciado pelo frontend, e por isto podemos ver que o mesmo é lido, escrito e persistido.

Integração com rotation=true

7 - Frontend - Protegendo um App SSR

Voltar ao Topo

Agora que concluímos as explicações sobre aplicações SPA, vamos falar sobre SSR, e neste caso o refresh_token deve ser compartilhado entre o server-side e o client-side, e por isto não podemos usar o flow=server e seremos forçados a armazenar o Refresh Token em um Cookie gerenciado pelo nosso Frontend.

De toda forma, temos duas opções, uma usando rotation=true, onde o armazenando no refresh_token será no client-side. Caso tenhamos que usar o rotation=false, teremos que armazenar no server-side e usar um ssrMiddleware para criar uma API intermediária entre o server-side e o client-side.

7.1 - Integrando a uma API com rotation=true

Voltar ao Topo

No caso do rotation=true a implementação é a mesma que usamos no SPA mode, mas iremos usar um CookieStorage ao invés do LocalStorage.

src/composables/auth.ts

import { ref, computed, Ref } from 'vue'
import { useStorage, StorageLike } from '@vueuse/core'
import jwtDecode from 'jwt-decode';
import { Cookies } from 'quasar';
import type { AxiosInstance } from 'axios'
import type { JwtPayload } from 'jwt-decode';

type Payload = JwtPayload & { roles: string[] }
interface LoginRequest {
  username: string;
  password: string;
}

const token = ref('')
let refresh: Ref<string>;
function useAuth (api: AxiosInstance, cookies: Cookies) {
  if (!refresh) {
    const opts = { path: '/', sameSite: 'Lax', secure: true }
    const storage: StorageLike = {
      getItem(key: string) {
        return JSON.stringify(cookies.get(key));
      },
      setItem(key: string, value: string) {
        const obj = JSON.parse(value);
        cookies.set(key, obj, opts);
      },
      removeItem: function (key: string): void {
        cookies.remove(key, opts);
      }
    }
    refresh = useStorage('refresh-token', '', storage)
  }

  async function login (req: LoginRequest) {
    const { data } = await api.post('/auth/login?flow=client&rotation=true');
    token.value = data.accessToken;
    refresh.value = data.refreshToken;
  }
  async function refresh (req: LoginRequest) {
    try {
      const { data } = await api.get('/auth/refresh?flow=client', {
        headers: {
          RefreshToken: refresh.value
        }
      });
      token.value = data.accessToken;
      refresh.value = data.refreshToken;
    } catch (error) {
      const res = error.response;
      if (res.status === 401) {
        token.value = '';
        refresh.value = '';
      }
    }
  }
  async function logout (req: LoginRequest) {
    await api.delete('/auth/logout?flow=client');
    token.value = '';
    refresh.value = '';
  }

  const payload = computed(() => {
    if (!token.value) {
      return null;
    }
    return jwtDecode(token.value) as Payload;
  })
  return {
    token,
    payload,
    login,
    refresh,
    logout
  }
}
Enter fullscreen mode Exit fullscreen mode

E na imagem abaixo, esta em destaque as alterações no composable:

Integração com rotation=true - SSR

E claro, como o composable agora está esperando os Cookies como argumento, nós precisamos fazer uma modificação no boot.

src/boot/axios.ts

import { boot } from 'quasar/wrappers';
import axios from 'axios';
import { InjectionKey } from 'vue';
import { useAuth } from 'src/composables/auth';
import { Cookies } from 'quasar';

export const apiKey: InjectionKey<AxiosInstance> = Symbol('api-key');
export default boot(async ({ app, store, router, ssrContext }) => {
  const cookies = process.env.SERVER 
    ? Cookies.parseSSR(ssrContext) 
    : Cookies;
  const url = process.env.API_URL;
  const api = axios.create({ baseURL: url });

  const { token, refresh } = useAuth(api, cookies);

  api.interceptors.request.use(
    function (config) {
      if (token.value) {
        config.headers ||= {}
        config.headers.Authorization = `Bearer ${token.value}`;
      }
      return config;
    },
    function (error) {
      return Promise.reject(error);
    }
  );

  api.interceptors.response.use(
    function (response) {
      return response;
    },
    async function (error) {
      const res = error.response;
      switch (res.status) {
        case 401:
          if (token.value) {
            await refresh()
            if (token.value) {
              return api.request(error.config);
            }
          }
          break;
      }
      return Promise.reject(error);
    }
  );
  await refresh();
})
Enter fullscreen mode Exit fullscreen mode

E mais uma vez, estou colocando em destaque as alterações relevantes.

Boot utilizado na Integração com rotation=true - SSR

7.2 - Integrando a uma API com rotation=false

Voltar ao Topo

Agora iremos falar sobre como utilizar o rotation=false com o modo SSR.

7.2.1 - Preparando o Server Side

Voltar ao Topo

No Server Side, teremos de extender a instancia do webserver que serve a aplicação SSR com uma mini API, podemos utilizar um SSRMiddleware para esta tarefa.:

quasar new ssrmiddleware auth
Enter fullscreen mode Exit fullscreen mode

importante: O ssrmiddleware deve ser adicionado ao quasar.config

Então iremos adicionar os endpoints /login, /refresh, /logout no nosso middleware

src/utils/index.ts

export const cookieName = 'REFRESH_TOKEN';
export function cookieOptions() {
  const expires = new Date();
  expires.setDate(expires.getDate() + 1);
  return {
    path: ['api', 'auth', 'refresh'].join('/'),
    secure: true,
    sameSite: 'lax',
    httpOnly: true,
    expires: expires,
  };
}
Enter fullscreen mode Exit fullscreen mode

src-ssr/middlewares/auth.ts

import { ssrMiddleware } from 'quasar/wrappers'
import { Router } from 'express';
import axios from 'axios';
import { cookieName, cookieOptions } from '../src/utils';

export default ssrMiddleware(async ({ app /*, resolveUrlPath, publicPath, render */ }) => {
  const url = process.env.API_URL;
  const api = axios.create({ baseURL: url });

  const router = Router()
  router.post('login', async function (req, res) {
    const { data } = await api.post('/auth/login?flow=client&rotation=false');
    res.cookie(cookieName, data.refreshToken, cookieOptions());
    res.json({
      accessToken: data.accessToken
    });
  })
  router.get('refresh', async function (req, res) {
    let accessToken = ''
    const refresh = req.cookies[cookieName];
    if (refresh) {
      const { data } = await api.get('/auth/refresh?flow=client');
      accessToken = data.value;
    }
    return {
      accessToken
    }
  })
  router.delete('logout', async function (req, res) {
    await api.get('/auth/logout?flow=client');
    res.clearCookie(cookieName)
  })
  app.use('/api/auth', router)
})
Enter fullscreen mode Exit fullscreen mode

Note que estamos usando o flow=client no nosso backend, mas na API interna do frontend estamos escrevendo um cookie, e este cookie estará disponível apenas no nosso server-side.

API Interna

7.2.2 - Comunicação entre o Server Side e o Client Side

Voltar ao Topo

Agora vamos ao nosso composable, ele vai permanecer praticamente o mesmo, mas quando estivemos no client-side, ao invés de chamar a API externa, ele irá chamar a API interna.

src/composables/auth.ts

import { ref, computed, Ref } from 'vue'
import { useStorage, StorageLike } from '@vueuse/core'
import jwtDecode from 'jwt-decode';
import { Cookies } from 'quasar';
import axios from 'axios';
import type { AxiosInstance } from 'axios'
import type { JwtPayload } from 'jwt-decode';
import { cookieName, cookieOptions } from 'src/utils';

type Payload = JwtPayload & { roles: string[] }
interface LoginRequest {
  username: string;
  password: string;
}

const token = ref('');
const internal = axios.create({ baseURL: '/api/auth/' });
function useAuth (api: AxiosInstance, cookies: Cookies) {
  async function login (req: LoginRequest) {
    const { data } = await internal.post('login');
    token.value = data.accessToken;
  }
  async function refresh (req: LoginRequest) {
    if (process.env.CLIENT) {
      const { data } = await internal.get('refresh');
      token.value = data.accessToken;
    }
    if (process.env.SERVER) {
      var refreshToken = cookies.get('REFRESH_TOKEN')
      try {
        const { data } = await api.get('/auth/refresh?flow=client', {
          headers: {
            RefreshToken: refreshToken
          }
        });
        token.value = data.accessToken;
        cookies.set(cookieName, data.refreshToken, cookieOptions());
      } catch (error) {
        const res = error.response;
        if (res.status === 401) {
          token.value = '';
          cookies.remove(cookieName, cookieOptions());
        }
      }
    }
  }
  async function logout (req: LoginRequest) {
    await internal.delete('logout');
    token.value = '';
  }

  const payload = computed(() => {
    if (!token.value) {
      return null;
    }
    return jwtDecode(token.value) as Payload;
  })
  return {
    token,
    payload,
    login,
    refresh,
    logout
  }
}
Enter fullscreen mode Exit fullscreen mode

E por fim os pontos de interrese:

Integração entre API Interna e Externa

Note que estamos sempre a chamar a API interna, com exceção do refresh, que caso seja executado do server-side irá chamar a API externa diretamente e atualizar o Cookie.

Top comments (1)

Collapse
 
helioh3 profile image
Helio Brito • • Edited

Excelente Tobias!

Read next

sbenhoff profile image

Scrum 101: A Beginner's Guide to Agile Project Management

Shelley Benhoff -

mursalfk profile image

Ultimate React Interview Study Plan: Your one-stop for your next #React Interview

Mursal Furqan Kumbhar -

nicooprat profile image

Restricting some syntax with ESLint

Nico Prat -

jawwad22 profile image

Learning Dart Futures, Async and Await Like Ordering Pizza

jawwad22 -