Como adicionar Authorization no request do Axios

Neste artigo você aprenderá a como colocar o Authorization no request do Axios, veja como é simples fazer isso!

Fala programador(a), beleza? Bora aprender mais sobre React JS!

O Axios é uma biblioteca popular de cliente HTTP baseada em promessas para fazer requisições AJAX tanto no navegador quanto no Node.js.

Uma das características mais poderosas do Axios é sua capacidade de configurar globalmente as configurações de requisição, incluindo cabeçalhos.

Uma aplicação comum disso é adicionar um cabeçalho de “Authorization” para autenticar requisições a uma API.

Neste artigo, vamos explorar como adicionar um cabeçalho de “Authorization” às suas requisições Axios em um projeto React JS, utilizando componentes funcionais.

Configurando o Axios Globalmente

Para muitas aplicações, é conveniente definir configurações globais para o Axios para que todas as requisições se beneficiem destas configurações.

Configuração Básica

import axios from 'axios';

// Configuração global do Axios
axios.defaults.headers.common['Authorization'] = 'Bearer SEU_TOKEN_AQUI';

Ao definir o cabeçalho “Authorization” dessa maneira, todas as subsequentes requisições feitas com o Axios incluirão esse cabeçalho.

Utilizando Axios em Componentes React

Vamos criar um componente React funcional que faz uma requisição a uma API e exibe os dados retornados.

Exemplo de Componente Funcional

import React, { useEffect, useState } from 'react';
import axios from 'axios';

const ListarDados = () => {
  const [dados, setDados] = useState([]);

  useEffect(() => {
    const buscarDados = async () => {
      try {
        const resposta = await axios.get('https://api.exemplo.com/dados');
        setDados(resposta.data);
      } catch (erro) {
        console.error('Houve um erro ao buscar os dados:', erro);
      }
    };

    buscarDados();
  }, []);

  return (
    <div>
      {dados.map(item => (
        <div key={item.id}>{item.nome}</div>
      ))}
    </div>
  );
};

Adicionando Authorization por Requisição

Se você não quiser definir o cabeçalho “Authorization” globalmente, ou se tiver vários tokens diferentes para usar, pode definir o cabeçalho por requisição.

Exemplo de Authorization por Requisição

const resposta = await axios.get('https://api.exemplo.com/dados', {
  headers: {
    Authorization: 'Bearer SEU_TOKEN_AQUI'
  }
});

Criando um Axios Instance

Para maior reutilização e organização, você pode criar uma “instância” do Axios com configurações predefinidas.

const api = axios.create({
  baseURL: 'https://api.exemplo.com',
  headers: {
    Authorization: 'Bearer SEU_TOKEN_AQUI'
  }
});

// Utilizando a instância em um componente React
const resposta = await api.get('/dados');

Cuidados e Considerações

Mantenha Seus Tokens Seguros

Nunca exponha seu token de autenticação no lado do cliente. Se estiver trabalhando com React no lado do cliente, considere utilizar proxies ou outras abordagens para manter seus tokens seguros.

Lide com Erros Adequadamente

Ao fazer requisições a APIs, especialmente com autenticação, sempre esteja preparado para lidar com erros, como tokens inválidos ou expirados.

Quer aprender mais sobre programação? Conheça nosso canal no YouTube:

Conclusão

Chegamos ao fim do artigo sobre como adicionar o Authorization no request do Axios!

O Axios oferece uma flexibilidade incrível para configurar e fazer requisições HTTP, tornando-o uma escolha popular para muitos desenvolvedores React.

Ao entender como adicionar cabeçalhos, como o “Authorization”, às suas requisições, você pode interagir com APIs protegidas de maneira eficiente e segura.

Está buscando em evoluir como Programador? Confira o nossos cursos de programação.

O problema do defaults global:

O axios.defaults é prático, mas ele é global de verdade

Ou seja: TODA requisição feita com o axios importado direto passa a carregar aquele header, inclusive a que vai pra uma API de terceiro que não tem nada a ver com o teu login

Mandar teu token de autenticação pra um domínio que não é o teu é vazamento de credencial, mesmo sem querer

Por isso a recomendação prática é: usa o defaults só em projeto pequeno, que fala com uma API só

Tendo mais de um destino, cria uma instância pra cada um (tem exemplo mais abaixo) e deixa o axios global limpo

Interceptor: mandando o token sem repetir código

Repara num detalhe do exemplo acima: a instância nasce com o token que existia no momento em que aquele arquivo foi importado

Se o usuário logar depois, ou se o token for renovado no meio da sessão, a instância continua carregando o valor velho

E aí vem o clássico "mas eu setei o header, por que a API diz que não estou autenticado?"

O interceptor resolve isso porque ele roda a CADA requisição, e não uma vez só

import axios from 'axios'

const api = axios.create({
baseURL: 'https://api.exemplo.com'
})

api.interceptors.request.use((config) => {
const token = localStorage.getItem('token')

if (token) {
config.headers.Authorization = `Bearer ${token}`
}

return config
})

export default api

Se tu já mexeu com middleware no backend, é a mesma ideia: um ponto único por onde tudo passa antes de sair

Depois disso é só chamar api.get('/dados') normal, que o header vai junto e sempre atualizado 🙂

(guardar token no navegador tem os seus poréns, falo disso na seção de segurança logo abaixo)

E quando o token expira?

Token de acesso costuma ter prazo, então mais cedo ou mais tarde a API vai te devolver um 401 no meio do uso

Dá pra centralizar esse tratamento num interceptor de resposta, em vez de espalhar try/catch por todo componente

api.interceptors.response.use(
(resposta) => resposta,
(erro) => {
if (erro.response && erro.response.status === 401) {
// token inválido ou expirado:
// aqui tu derruba a sessão ou dispara a renovação
}

return Promise.reject(erro)
}
)

Tome cuidado com um detalhe aqui!

Se a tua rotina de renovação usar a MESMA instância e ela também responder 401, tu entra em loop infinito de requisição

O jeito de escapar é marcar a requisição que já foi repetida uma vez (uma flag no próprio config) e não tentar de novo

Já me ferrei com isso, o navegador vira uma metralhadora de requisição haha

Por que o Authorization não está chegando na API?

Antes de culpar o axios, abre a aba Network do navegador, clica na requisição e olha os Request Headers

Se o Authorization não aparece ali, o problema é no front, e quase sempre é uma destas:

O token ainda era null na hora em que o header foi montado (usuário não tinha logado, ou o valor veio de uma chamada assíncrona que não terminou)

Faltou o espaço depois do esquema: é Bearer TOKEN, tudo dentro da MESMA string

O "Bearer" foi escrito duas vezes, porque a API já devolve o token com o prefixo e o código coloca de novo

A requisição sai de uma instância diferente da que recebeu a configuração

Agora, se o header aparece e a resposta continua ruim, olha o status: 401 quer dizer "não sei quem tu é" (token ausente, inválido ou expirado) e 403 quer dizer "sei quem tu é, mas tu não pode isso" (é permissão, não é o header)

São problemas diferentes, e confundir os dois faz a pessoa passar horas mexendo no lugar errado

Erro de CORS depois de colocar o Authorization:

Esse pega muita gente de surpresa: a requisição funcionava, tu adiciona o header e o navegador começa a reclamar de CORS

Não é bug do axios

Mandar um cabeçalho como o Authorization faz o navegador enviar antes uma requisição de verificação (o preflight, com o método OPTIONS) pra perguntar ao servidor se aquilo é permitido

Se o servidor não responder que aceita o cabeçalho Authorization (é o Access-Control-Allow-Headers que faz esse papel), o navegador barra e a tua requisição de verdade nem chega a sair

Ou seja: a correção é do lado do servidor, ou de quem mantém a API

Nenhuma configuração de axios no front resolve isso, porque quem está bloqueando é o navegador

Onde o token deve morar então?

Vale reforçar o porquê: tudo que entra no código do front vai pro navegador do usuário

Não existe esconderijo ali, é só abrir o devtools e ler

Então a régua é simples: chave secreta de API, credencial de administrador ou qualquer coisa que valha pra todo mundo NUNCA sai do servidor

Se o teu projeto tem uma camada de servidor (uma rota de API própria, um BFF, um proxy), é lá que a chave fica: o front chama a tua rota, a tua rota chama a API externa com a credencial e devolve só o resultado

Já o token de sessão do próprio usuário é outra história, ele precisa mesmo estar no navegador pra tua aplicação funcionar

O cuidado nesse caso muda de lugar: prazo curto de validade, renovação e derrubar a sessão quando a API responder 401

Quem escolhe onde guardar (armazenamento do navegador, memória, cookie) tem que pesar os riscos de cada um, não existe opção sem contrapartida

Nem toda API usa Bearer:

O Bearer é só o esquema mais comum, não é uma regra do axios nem do HTTP

Tem API que usa Basic (com usuário e senha codificados), tem API que espera o token cru no Authorization, sem prefixo nenhum, e tem API que ignora o Authorization e pede um cabeçalho próprio pra chave

A fonte da verdade é sempre a documentação de quem mantém a API que tu está consumindo

O axios não liga pro conteúdo: ele só entrega o cabeçalho do jeito que tu escreveu