LinkedIn
Instagram
WhatsApp
Telegrama
Google Agenda
Participe da comunidade do SlackAPI OAuth de E-mail: Autenticar Caixas de Correio de Usuário O Caminho Certo
Pare de armazenar senhas. Uma API de e-mail OAuth permite que seu aplicativo acesse caixas de entrada de usuários de forma segura - usando tokens revogáveis e com escopo limitado de provedores Gmail, Outlook e IMAP. Este guia cobre todos os fluxos OAuth, todos os escopos, todos os erros e como lançar em 5 minutos com uma camada de autenticação unificada hospedada.
// Conecta qualquer caixa de correio de usuário via OAuth - 1 chamada de API
const response = await fetch(
'https://api6.unipile.com:13226/api/v1/hosted/accounts/link',
{
method: 'POST',
headers: {
'X-API-KEY': 'SUA_CHAVE_DE_API',
'Content-Type': 'application/json'
},
body: JSON.stringify({
tipo: 'Google', // ou MICROSOFT, IMAP
nome: 'usuário_123'
})
}
);
const { url } = await resposta.json();
// Redireciona o usuário para a URL - OAuth tratado pelo Unipile
O que é uma API de E-mail OAuth?
Um API de Email OAuth é uma interface programática que concede ao seu aplicativo acesso às caixas de correio de usuários usando tokens OAuth 2.0 – sem nunca lidar ou armazenar a senha do usuário. Em vez de pedir credenciais aos usuários, você os redireciona pela tela de consentimento do provedor, recebe um token de acesso de curta duração e o usa para ler, enviar ou sincronizar e-mails em nome deles. A distinção é importante: trata-se de acessar caixas de correio de propriedade do usuário (Gmail, Outlook, e-mail pessoal), não enviar e-mails transacionais através de serviços de retransmissão SMTP como o SendGrid.
Um API de Email OAuth é uma combinação de um fluxo de autorização OAuth 2.0 (para autenticar um usuário e obter acesso delegado) e uma API de e-mail (para ler, enviar, pesquisar ou sincronizar a caixa de entrada desse usuário). A camada OAuth gera um token de acesso criptograficamente assinado, revogável e com escopo limitado. A API de e-mail consome esse token para interagir com Gmail, Outlook ou qualquer caixa de correio compatível com IMAP - tudo isso sem nunca saber a senha do usuário.
- Armazena senhas em texto plano ou criptografadas em seu banco de dados
- Acesso completo à caixa de correio - sem controle de escopo
- Bloqueado por Google/Microsoft desde 2026
- Responsabilidade GDPR/SOC2 para o armazenamento de credenciais
- Armazenamento zero de senhas - apenas tokens de curta duração
- Escopos granulares - somente leitura, somente envio ou completo
- Revogável a qualquer momento pelo usuário
- Em conformidade com GDPR, SOC2
Por que o OAuth Substituiu o Acesso a E-mail Baseado em Senha
Usar IMAP com nome de usuário e senha costumava ser a maneira padrão de acessar e-mails de usuários programaticamente. Essa era acabou. O Google desativou a autenticação básica para o Gmail em 2022, e a Microsoft concluiu o desligamento da autenticação básica para o Exchange Online em outubro de 2022, com a varredura final para protocolos restantes em 2026. Se o seu aplicativo ainda depende de acesso IMAP baseado em senha, ele já está quebrado ou quebrará em breve.
Tokens OAuth são de curta duração (geralmente 1 hora) e com escopo limitado. Mesmo que vazados, não podem ser usados para fazer login como o usuário, alterar sua senha ou acessar outros serviços. Você nunca toca nas credenciais do usuário.
A Microsoft concluiu a desativação da autenticação básica para Exchange Online e IMAP legado em 2026. Qualquer aplicativo que ainda use nome de usuário + senha para acessar caixas de correio do Outlook ou Microsoft 365 receberá erros 401 Não Autorizado.
Armazenar senhas de usuários – mesmo que hashadas – cria uma responsabilidade de conformidade. O princípio de minimização de dados da GDPR exige que você não colete o que não precisa. Auditores SOC2 sinalizam o armazenamento de credenciais.
Crítico: Google App Passwords e os protocolos legados da Microsoft não são mais suficientes para aplicações de produção. Se você estiver construindo um produto que acessa caixas de correio de usuários, um API de Email OAuth não é opcional - é o único caminho compatível daqui para frente em 2026.
Como o OAuth Funciona para APIs de E-mail (Passo a Passo)
O fluxo de código de autorização é o fluxo padrão do OAuth 2.0 para aplicações do lado do servidor que precisam acessar o e-mail do usuário. Compreendê-lo ponta a ponta ajuda você a implementá-lo corretamente, depurar falhas de token e explicar o fluxo à sua equipe de segurança.
Você constrói uma URL com seu id_cliente, a redirect_uri, o solicitado escopo, aleatório estado parâmetro (proteção CSRF) e tipo_de_resposta=código. O usuário é enviado para a tela de consentimento do Google ou da Microsoft.
A tela de consentimento exibe o nome do seu aplicativo, o logotipo e as permissões exatas que você solicitou. O usuário aprova (concede consentimento) ou nega. Solicitar muitos escopos nesta etapa é a causa mais comum de rejeição de consentimento.
Após o consentimento, o provedor redireciona para o seu redirect_uri com uma curta duração código parâmetro (válido por ~10 minutos). Verifique o estado parâmetro corresponde ao que você enviou para prevenir ataques CSRF.
POST de servidor para servidor para o endpoint de token com o seu id_cliente, segredo_do_cliente, o códigoe grant_type=authorization_code. Você recebe um token_de_acesso e (se você solicitou acesso offline) um token_de_atualização.
Passe o token de acesso em Autorização: Bearer cabeçalho em toda requisição da API. Quando expirar (geralmente após 1 hora), use o refresh token para obter um novo access token sem interação do usuário.
Tokens de acesso vs. tokens de atualização: ciclo de vida
Válido por 1 hora (Google) ou 1 hora (Microsoft). Passado no cabeçalho Authorization em cada chamada de API. Quando expirar, sua chamada de API de e-mail do OAuth retornará um erro 401 - o sinal para atualizar.
Válido até revogado (Google) ou 90 dias de inatividade (Microsoft). Nunca enviado para endpoints de API - usado apenas de servidor para servidor para obter novos tokens de acesso. Deve ser criptografado em repouso.
Crie um fluxo OAuth unificado em minutos
Pule complicações de autorização por provedor. Uma chamada de API Unipile substitui três integrações OAuth.
Fluxos OAuth por Provedor: Google e Microsoft
Google e Microsoft implementam o OAuth 2.0 de maneiras diferentes - endpoints de autorização diferentes, escopos diferentes, endpoints de token diferentes e processos de verificação diferentes. O IMAP é o fallback baseado em credenciais para provedores sem OAuth padronizado. Aqui está o que você precisa saber para cada caso.
A implementação OAuth do Google usa o fluxo de código de autorização padrão. O endpoint de token é https://oauth2.googleapis.com/token. A complexidade crítica é o Google CASA (Cloud Application Security Assessment): assim que seu aplicativo ultrapassar 100 usuários, você precisará passar por uma revisão de segurança. Para escopos sensíveis como gmail.modificar ou gmail.somente leitura, A Verificação do Aplicativo é necessária antes do uso em produção. Para um completo Integração da API do Gmail: mergulho profundo, veja nosso guia dedicado. Os detalhes de implementação estão no Documentação do Google OAuth da Unipile.
Código de autorização do Exchange # para acesso ao Gmail + tokens de atualização
enrolar -X POST https://oauth2.googleapis.com/token \
-d "código=AUTH_CODE" \
-d "client_id=SEU_CLIENT_ID" \
-d "client_secret=SEU_CLIENT_SECRET" \
-d "redirect_uri=https://seusite.com/callback" \
-d "grant_type=authorization_code"
Resposta #: { "access_token": "...", "refresh_token": "...", "expires_in": 3600 }
A Microsoft utiliza sua Plataforma de Identidade (anteriormente Azure AD v2). O endpoint de token é https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token. A Verificação do Editor é necessária antes que seu aplicativo de API de e-mail OAuth possa solicitar escopos de email confidenciais em produção. A Microsoft desativou a autenticação básica para todos os protocolos do Exchange Online - o OAuth é obrigatório. Veja nosso Guia completo de e-mail do Microsoft Graph para mais detalhes, e o Documentação do Microsoft OAuth da Unipile para referência de implementação.
Código de troca # para tokens OAuth da Microsoft
enrolar -X POST https://login.microsoftonline.com/common/oauth2/v2.0/token \
-d "código=AUTH_CODE" \
-d "client_id=SEU_CLIENT_ID" \
-d "client_secret=SEU_CLIENT_SECRET" \
-d "redirect_uri=https://seusite.com/callback" \
-d "grant_type=authorization_code" \
-d "escopo=https://graph.microsoft.com/Mail.Read offline_access"
Resposta #: { "access_token": "...", "refresh_token": "...", "expires_in": 3600 }
IMAP não é um provedor OAuth: é um protocolo que se autentica com nome de usuário/senha, ou senhas de aplicativo (como uma Senha de Aplicativo do Google ou senha gerada pelo iCloud). É o recurso de fallback para servidores de e-mail personalizados, domínios corporativos não incluídos no Microsoft 365 e qualquer provedor sem um fluxo OAuth padronizado. XOAUTH2 existiu como uma extensão SASL do IMAP para um pequeno número de provedores, mas foi em grande parte abandonado, com o Yahoo descontinuando sua implementação própria em 2022. Para a maioria das implementações IMAP, o Unipile se autentica diretamente com as credenciais. Veja o completo Guia de integração IMAP para configuração do servidor e detalhes de autenticação.
import base64, imaplib
# Gerar a string XOAUTH2 a partir do token de acesso OAuth
def build_xoauth2(email_do_usuário, token_de_acesso):
auth_str = f"usuário={user_email}\x01autenticação=Bearer {access_token}\x01\x01"
return base64.b64encode(auth_str.encode()).decode()
#: Conecte-se via IMAP com XOAUTH2
conexão = imaplib.IMAP4_SSL("imap.mail.yahoo.com")
auth_str = build_xoauth2("user@yahoo.com", access_token)
conexão.autenticar("XOAUTH2", lambda x: auth_str)A Complexidade Oculta do OAuth Multi-Provedor
Implementar uma API de e-mail OAuth para um provedor leva alguns dias. Implementá-la corretamente para Gmail, Outlook e IMAP - com gerenciamento de tokens, tratamento de erros e conformidade de nível de produção - geralmente leva de 4 a 8 semanas de tempo de engenharia. Eis o porquê.
Google Cloud Console, Azure Portal e Yahoo Developer Network são 3 painéis completamente diferentes com UX diferentes, fluxos de registro de aplicativos diferentes e requisitos de verificação diferentes. Qualquer rotação de credenciais afeta todos os 3.
Escopos sensíveis do Gmail (incluindo gmail.somente leitura) ficam limitados a 100 usuários até que você seja aprovado na avaliação CASA Nível 2. Isso envolve um laboratório autorizado pela CASA, um teste de penetração e uma análise formal de segurança — o que normalmente leva de 6 a 12 semanas e custa entre 10.000 e 25.000 dólares.
A Microsoft exige a Verificação do Editor para aplicativos que solicitam escopos de e-mail confidenciais. Sem isso, os usuários verão um aviso vermelho de "editor não verificado" na tela de consentimento. O processo de verificação exige uma conta ativa na Microsoft Partner Network com um domínio verificado.
Os tokens de atualização do Google expiram após 6 meses de inatividade (ou imediatamente se o usuário revogar). Os tokens da Microsoft expiram após 90 dias de inatividade. Os tokens XOAUTH2 do Yahoo/IMAP têm durações específicas do provedor. Sua camada de gerenciamento de tokens deve lidar com todos os 3 de maneira diferente.
Google, Microsoft e Yahoo exibem telas de consentimento de maneiras diferentes – branding diferente, descrições de escopo diferentes, padrões de interface diferentes. Seus usuários veem 3 fluxos diferentes dependendo do provedor de e-mail, criando uma experiência de usuário inconsistente e maiores taxas de abandono.
Endpoints do OAuth mudam. Nomes de escopos são descontinuados. Novos requisitos de segurança são adicionados. Cada provedor anuncia alterações disruptivas em prazos diferentes. Alguém em sua equipe precisa acompanhar 3 blogs de provedores, 3 changelogs e 3 calendários de conformidade - indefinidamente.
Evite a complexidade do OAuth totalmente
Autenticação hospedada, gerenciamento de escopos e tratamento de atualizações. A Unipile cuida de tudo para que você possa focar no seu produto.
Arquitetura de API de E-mail OAuth: 3 Abordagens Comparadas
Existem 3 arquiteturas para construir uma camada de API de e-mail OAuth. Cada uma possui um custo de implementação, carga de manutenção e perfil de segurança fundamentalmente diferentes. A escolha certa depende se a conectividade de e-mail é o seu produto principal ou um recurso que você está lançando ao lado do seu produto principal.
| Dimensão | Provedor Direto OAuth (x3) | Gateway OAuth Auto-hospedado | OAuth Unificado Hospedado (Unipile) Recomendado |
|---|---|---|---|
| Tempo para a primeira caixa de correio conectada | 3-7 dias (por provedor) | 2-4 semanas | 5 minutos |
| Fluxos OAuth a serem implementados | 3 fluxos separados | 3 fluxos + lógica de roteamento | 1 ponto de extremidade de link hospedado |
| Revisão do Google CASA | Você cuida disso (6 a 12 semanas, $10k+) | Você cuida disso | Gerenciado pela Unipile |
| Verificação do Microsoft Publisher | Você cuida disso | Você cuida disso | Gerenciado pela Unipile |
| Gerenciamento de renovação de token | 3 estratégias para construir | Personalizado por provedor | Automático, transparente |
| API de leitura/envio de e-mail | 3 APIs diferentes | Camada de abstração necessária | 1 API REST unificada |
| Webhook para novos e-mails | Push/pull para provedor | Personalizado | Eventos unificados de webhook |
| Conformidade com SOC2 / GDPR | Sua responsabilidade | Sua responsabilidade | Unipile tem certificação SOC2 |
| Manutenção contínua | Alto (3 changelogs de provedor) | Alta | Zero - tratado pela Unipile |
| Melhor para | Produtos nativos de e-mail de provedor único | Grandes equipes com infra dedicada | Qualquer time que envia rápido |
Construir vs Comprar: API OAuth de E-mail Hospedada em 5 Minutos
Em vez de construir 3 fluxos OAuth separados, o Unipile fornece um link de autenticação hospedado que cuida do OAuth do Google, Microsoft Identity e IMAP para você. Seu aplicativo gera um link, redireciona o usuário e recebe um webhook quando a caixa de correio é vinculada. A API de e-mail OAuth fica imediatamente utilizável - sem configuração no console, sem revisão do CASA, sem lógica de atualização de token para construir.
Passo 1: Gerar um link de autenticação hospedado
Uma chamada de API para criar uma sessão de autenticação hospedada. Especifique o tipo de provedor e um nome para a conta. Unipile retorna uma URL para redirecionar seu usuário para a tela de consentimento do OAuth.
// Conectar usuário do Gmail via API de e-mail OAuth hospedada pela Unipile
const response = await fetch(
'https://api6.unipile.com:13226/api/v1/hosted/accounts/link',
{
method: 'POST',
headers: {
'X-API-KEY': 'CHAVE_API_UNIPILO_SEU',
'Content-Type': 'application/json'
},
body: JSON.stringify({
tipo: 'Google',
nome: 'usuario_alice_123',
success_redirect_url: 'https://seunovoapp.com/conectado',
url_redirecionamento_falha: 'https://seusite.com/erro'
})
}
);
const { url, objeto } = await resposta.json();
// Redireciona o usuário para a URL - Unipile cuida do consentimento OAuth
window.location.href = url;Passo 2: Conectar um usuário do Outlook
Mesmo endpoint, mesmo padrão. Mude tipo para MICROSOFT. No Portal do Azure, na Verificação do Publicador para gerenciar do seu lado.
import solicitações
#: Conectar usuário do Outlook por meio da API de e-mail OAuth da Unipile
response = pedidos.postagem(
"https://api6.unipile.com:13226/api/v1/hosted/accounts/link",
cabeçalhos={"X-API-KEY": "SUA_CHAVE_DE_API_UNIPILE"},
json={
"tipo": "MICROSOFT",
"nome": "usuário_bob_456",
"url_de_redirecionamento_de_sucesso": "https://seusite.com/ativo"
}
)
auth_url = response.json()["url"]
# Redirecionamento para auth_url - Fluxo de identidade da Microsoft gerenciado pelo UnipileEtapa 3: Receber o webhook em account.connected
Após o consentimento do OAuth, o Unipile dispara um webhook para o seu endpoint. A carga útil do evento inclui o novo account_id - que você armazena e usa para todas as subsequentes ler email API e API de envio de e-mail chamadas.
Evento de webhook: Quando um usuário completa o OAuth, o Unipile envia um account.connected evento para a URL do seu webhook. A carga útil (payload) contém o account_id (guarde isto), o provider (GOOGLE / MICROSOFT / IMAP) e o endereço de e-mail vinculado. Este é o único estado que você precisa persistir - o Unipile gerencia todos os tokens OAuth internamente.
Pule a implementação do OAuth em 8 semanas. Conecte caixas de correio em minutos.
A API de e-mail OAuth hospedada da Unipile lida com Google CASA, Verificação do Publicador Microsoft, XOAUTH2 e atualização de token para todos os provedores. Seus usuários vinculam sua caixa de correio por meio de um único fluxo hospedado - você obtém uma API unificada para ler, enviar e sincronizar.
Gerenciando Tokens OAuth: Atualizar, Revogar, Rotacionar
O gerenciamento de tokens é a parte mais exigente operacionalmente da construção de uma API de e-mail OAuth. Tokens de acesso expiram, tokens de atualização são revogados por usuários e seu sistema deve lidar com tudo isso de forma graciosa – ou arriscar que seus usuários percam o acesso às suas caixas de correio silenciosamente.
Melhores práticas para armazenamento de tokens
- Criptografe tokens de atualização em repouso usando AES-256 ou um KMS em nuvem (AWS KMS, GCP Cloud KMS, Azure Key Vault). Nunca os armazene em texto puro em seu banco de dados.
- Nunca registre tokens de acesso ou tokens de atualização. Sistemas de log estruturado como Datadog ou Splunk devem ter campos de token mascarados ou redigidos.
- Armazene tokens em um repositório de segredos dedicado (Vault, AWS Secrets Manager) em vez de no banco de dados principal do seu aplicativo, para minimizar o raio de explosão caso o banco de dados seja comprometido.
- Implemente a rotação de tokens: ao obter um novo token de atualização em uma chamada de refresh (alguns provedores emitem novos tokens de atualização a cada uso), invalide o antigo imediatamente.
Lidar graciosamente com falhas de atualização
Quando um token de atualização expira ou é revogado, sua chamada de atualização retorna um erro 400 ou 401. Sua API de e-mail OAuth deve capturar isso e acionar um fluxo de reautenticação para o usuário - não falhar silenciosamente. O pior resultado é um usuário que acha que os e-mails estão sendo lidos, mas o token foi revogado por semanas. Crie uma verificação explícita de saúde da conta e alerte os usuários quando a reautenticação for necessária.
Escopos do OAuth: O Que Solicitar (e o Que Não Solicitar)
A minimização de escopo é uma prática recomendada de segurança e uma estratégia de otimização de consentimento. Solicitar mais escopos do que o necessário faz com que os usuários hesitem (ou rejeitem) na tela de consentimento e aciona um escrutínio elevado durante as revisões do Google CASA e do Microsoft Publisher.
| Escopo | Fornecedor | Caso de uso | Sensibilidade | Revisão do CASA? |
|---|---|---|---|---|
| gmail.somente leitura | Gmail | Ler todos os e-mails e metadados | Alta | Sim - Nível 2 |
| gmail.enviar | Gmail | Enviar e-mail como o usuário | Alta | Sim - Nível 2 |
| gmail.modificar | Gmail | Ler, enviar, excluir, marcar | Alta | Sim - Nível 2 |
| gmail.marcadores | Gmail | Ler e gerenciar rótulos apenas | Baixa | Não |
| Mail.Read | Perspectivas | Ler todo o correio | Médio | Verificação do Editor |
| Mail.Send | Perspectivas | Enviar e-mail como usuário | Médio | Verificação do Editor |
| Mail.ReadWrite | Perspectivas | Ler, enviar, excluir, gerenciamento de pastas | Alta | Verificação do Editor |
| acesso_offline | Perspectivas | Obter tokens de atualização | Baixa | Não |
| correio-r | IMAP (Yahoo) | Ler e-mail via IMAP/XOAUTH2 | Médio | Revisão do desenvolvedor do Yahoo |
Tokens atualizados e rotacionados para você
Pare de escrever código do ciclo de vida de tokens. Conecte uma caixa de correio uma vez, o Unipile mantém o acesso ativo em todos os provedores.
Conformidade: SOC2, GDPR, CASA
Uma API de e-mail OAuth que gerencia caixas de correio de usuários fica na interseção entre segurança e conformidade de privacidade. Aqui estão os quatro frameworks sobre os quais a maioria dos compradores empresariais perguntará - e o que o modelo de token do OAuth significa para cada um deles.
Auditores SOC2 analisam o manuseio de tokens como parte dos critérios de Disponibilidade e Confidencialidade. Tokens OAuth devem ser criptografados em repouso (AES-256 ou KMS), ter acesso registrado em log e estar sujeitos a uma política formal de rotação. Armazenar tokens de atualização em texto plano é uma constatação automática. O uso de uma API de e-mail OAuth hospedada como a Unipile (que é certificada SOC2) transfere essa responsabilidade.
Sob o GDPR, seu aplicativo é um processador de dados quando acessa o conteúdo de e-mail do usuário. Você precisa de um DPA (Acordo de Processamento de Dados) com seu provedor de infraestrutura de API de e-mail OAuth. A revogabilidade do OAuth atende diretamente ao Artigo 17 (direito ao apagamento) - quando um usuário revoga, seu acesso termina imediatamente. Documente sua base legal para acessar dados de e-mail (geralmente consentimento por meio do fluxo OAuth).
Quando seu aplicativo da API de e-mail do Gmail OAuth ultrapassar 100 usuários com escopos confidenciais, o Google bloqueará novas adições de usuários até que você seja aprovado no CASA Nível 2. Isso requer um teste de penetração realizado por um laboratório autorizado pelo CASA, um questionário de segurança e um relatório de avaliação formal enviado ao Google. Prazo: 8 a 16 semanas. Custo: 10.000–25.000 TP4T. Os aplicativos verificados recebem o selo "Verificado pelo Google" em sua tela de consentimento.
OAuth Email API: Modelos de Precificação e Custo
As APIs gratuitas de provedores do Google e da Microsoft ocultam custos reais significativos. Aqui está um modelo de custo realista para implementar uma API de e-mail OAuth em escala - cobrindo a rota direta do provedor versus APIs unificadas.
As APIs do Google e da Microsoft são tecnicamente gratuitas no nível das chamadas de API. No entanto: o plano CASA Tier 2 do Google custa entre 10 mil e 25 mil TP4T e requer mais de três meses de trabalho de engenharia. A verificação de editores da Microsoft exige uma conta na Rede de Parceiros e a verificação legal do domínio. Tempo de engenharia necessário para criar três fluxos, gerenciamento de tokens e tratamento de erros: 6 a 10 semanas. Manutenção anual: 2 a 4 semanas por ano por provedor.
A API de e-mail OAuth da Unipile inclui conformidade de todos os provedores (CASA, Verificação de Editor), gerenciamento de tokens e uma API unificada de e-mail sob uma única assinatura. Para equipes que implementam conectividade de e-mail como um recurso (não um produto), o cálculo de ROI é direto: semanas de tempo de engenharia economizadas em comparação com um custo mensal da API. Veja o Compare provedores de API de e-mail guia para um detalhamento completo de custos.
Armadilhas Comuns na Implementação do Email OAuth
Estes são os erros mais comuns que os desenvolvedores cometem ao construir uma API de e-mail OAuth pela primeira vez – e o que fazer em vez disso.
O Google invalida tokens de atualização se o usuário não utiliza seu aplicativo por 6 meses. Sua chamada de atualização de token retorna concessão_inválida. Correção: implementar uma "verificação de integridade do token" periódica que faça uma chamada leve à API do Gmail para cada conta vinculada pelo menos uma vez a cada 30 dias para evitar a expiração por inatividade.
Solicitando gmail.modificar quando você só precisa gmail.somente leitura infla sua tela de consentimento e faz com que os usuários abandonem o fluxo OAuth. Também aumenta seu requisito de nível CASA. Sempre solicite o escopo mínimo necessário. Você pode solicitar escopos adicionais incrementalmente mais tarde.
O limite de escopo sensível do Gmail de 100 usuários é o bloqueador de crescimento mais comum para implementações de API de e-mail OAuth. Planeje a revisão da CASA antes de atingir 50 usuários - a revisão leva de 8 a 16 semanas, e o crescimento de seus usuários será bloqueado enquanto ela estiver pendente.
O registro detalhado de requisições que captura cabeçalhos de Autorização registrará seus tokens de acesso em texto puro. Implemente middleware de limpeza de logs que ofusca Portador [TOKEN] padrões antes que os logs sejam gravados em qualquer armazenamento persistente.
Alguns servidores de e-mail corporativos rodam atrás de configurações IMAP personalizadas que não suportam OAuth. Sua API de e-mail OAuth deve ter um caminho de fallback gracioso para provedores apenas IMAP. Incorpore isso no seu fluxo de conexão de conta desde o primeiro dia, ou você excluirá um segmento significativo de usuários B2B. Veja nosso Integração IMAP Guia para o padrão de fallback completo.
Construir em vez de costurar provedores juntos
Obtenha uma integração de e-mail OAuth funcional hoje mesmo. Nível gratuito, sem cartão de crédito, escopos completos do Gmail e Microsoft disponíveis.
Perguntas frequentes
As perguntas mais comuns que os desenvolvedores fazem ao criar uma integração de API de e-mail OAuth - respondidas precisamente.
https://oauth2.googleapis.com/token, escopos em gmail.* namespace. Para o Outlook (abrangendo Outlook.com, Microsoft 365 e Exchange Online): Plataforma de Identidade da Microsoft, endpoint de token https://login.microsoftonline.com/common/oauth2/v2.0/token, escopos sob https://graph.microsoft.com/. Para IMAP: IMAP não é um provedor OAuth. Ele usa credenciais de nome de usuário/senha ou senha de aplicativo. O XOAUTH2 existiu como uma extensão SASL para um pequeno número de provedores, mas foi amplamente descontinuado.grant_type=refresh_token. Para o Google: POST para https://oauth2.googleapis.com/token. Para a Microsoft: POST para https://login.microsoftonline.com/common/oauth2/v2.0/token. Se você receber concessão_inválida, O token de atualização expirou ou foi revogado - solicite ao usuário que se autentique novamente.gmail.somente leitura para ler, gmail.enviar para enviar, gmail.modificar para leitura/gravação/exclusão completa. Para Outlook: Mail.Read para ler, Mail.Send para enviar, Mail.ReadWrite para acesso total - plus acesso_offline para obter tokens de atualização. Sempre solicite o escopo mínimo que seu caso de uso exige. Veja o Página da API de e-mail para recomendações de escopo específicas para casos de uso.gmail.marcadores (não sujeito ao CASA), inicie o processo do CASA antes de atingir 50 usuários (leva de 8 a 16 semanas), ou use uma API de e-mail OAuth hospedada como a Unipile, cuja infraestrutura já passou pela revisão do CASA - eliminando este requisito para sua aplicação inteiramente./api/v1/hosted/accounts/link. Você passa por um tipo (GOOGLE, MICROSOFT ou IMAP) e a Unipile gera uma URL de autenticação hospedada. O usuário completa o consentimento OAuth na infraestrutura da Unipile, que passou pela Verificação de Editor do Google CASA e da Microsoft. Após o consentimento, a Unipile envia um webhook com o account_id. Todo o gerenciamento e atualização de tokens é tratado internamente.concessão_inválida. Sua API de e-mail OAuth deve capturar isso, marcar a conta vinculada como desconectada e notificar o usuário com um link de reautenticação. Com o Unipile, um webhook de revogação é acionado automaticamente para que seu sistema seja notificado em tempo real - sem necessidade de polling.
BR 
EN 
FR 
ES 
DE 
IT 
NL 
PL 
TR