--- term: 'OAuth 2.0 & Login Social' seoTitle: 'OAuth 2.0 e Login Social: Fluxos, Tokens, PKCE, Vinculação de Contas' headline: 'O que são OAuth 2.0 e Login Social?' slug: oauth-2-login-social category: auth-security shortDefinition: 'OAuth 2.0 é um padrão de autorização que permite a um app acessar a conta de um usuário em outro serviço — o login social constrói a autenticação por cima.' relatedTerms: - json-web-token-jwt - passwordless-authentication - identity-access-management-iam - multi-factor-authentication-mfa contrastsWith: - json-web-token-jwt aboutTerms: - 'OAuth 2.0' - 'OpenID Connect (OIDC)' - 'Login Social' - 'PKCE' faq: - question: 'O que é OAuth 2.0 em termos simples?' answer: 'Um padrão que permite a um app obter acesso limitado à sua conta em outro serviço sem que você entregue a senha. Em vez de credenciais, o serviço emite para o app um token temporário e com escopo — como um cartão de hotel que abre o seu quarto e a academia, mas não a sala do gerente, e expira no checkout.' - question: 'OAuth é autorização ou autenticação?' answer: 'Autorização — pelo título da própria especificação, a RFC 6749 é "The OAuth 2.0 Authorization Framework". Ela responde "o que este app pode acessar?", não "quem é este usuário?". O login em cima do OAuth é padronizado pelo OpenID Connect, que adiciona um ID token assinado atestando a identidade para o app.' - question: 'Qual a diferença entre OAuth 2.0 e OpenID Connect?' answer: 'O OpenID Connect é uma camada fina de identidade sobre o OAuth 2.0: os mesmos fluxos, mais um ID token assinado (um JWT endereçado ao seu app, com claims de issuer, subject, audience e nonce) e um endpoint de userinfo. Todo botão real de "Entrar com…" é OIDC ou um equivalente do provedor — o OAuth puro não define como provar quem fez login.' - question: 'Quais são os grant types do OAuth?' answer: 'Authorization code com PKCE para qualquer coisa envolvendo um usuário; client credentials para comunicação máquina a máquina; device authorization para TVs e CLIs; refresh token para renovar o acesso. Os grants implicit e password são legado — ambos foram removidos no OAuth 2.1, e projetos novos nunca deveriam usá-los.' - question: 'O que são access tokens e refresh tokens?' answer: 'O access token é a credencial de vida curta que o app apresenta à API — com escopo, com expiração, muitas vezes um JWT. O refresh token vive mais e é trocado por novos access tokens sem incomodar o usuário de novo; a prática moderna o rotaciona a cada uso, para que um token roubado morra no primeiro replay.' - question: 'O que é PKCE e por que é obrigatório?' answer: 'Proof Key for Code Exchange (lê-se "pixie"): o app inicia o fluxo com um segredo hasheado e precisa apresentar o original ao resgatar o authorization code, provando que quem resgata é quem iniciou. Criado para apps móveis, que não conseguem guardar client secrets, ele defende contra interceptação de código — e o OAuth 2.1 o exige de todo cliente.' - question: 'O que é login social e como ele funciona?' answer: 'É o OIDC embalado como botão: o app redireciona para o endpoint de autorização do provedor; o usuário se autentica lá — a senha nunca toca o app — e consente; o provedor redireciona de volta com um código de uso único; o app o troca por tokens e lê o subject estável do ID token para criar ou encontrar a conta local.' - question: 'Login social é seguro?' answer: 'Em geral, sim: o usuário herda a autenticação endurecida e a MFA do provedor em vez de mais uma senha reutilizada. Os custos são o risco de concentração — uma conta bloqueada ou comprometida no provedor afeta todos os apps rio abaixo — e o cuidado de implementação: o app deve ancorar a identidade no subject estável do provedor e em claims verificados, nunca em um campo cru de e-mail.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'RFC 6749 — The OAuth 2.0 Authorization Framework' url: 'https://datatracker.ietf.org/doc/html/rfc6749' - name: 'RFC 7636 — Proof Key for Code Exchange (PKCE)' url: 'https://datatracker.ietf.org/doc/html/rfc7636' - name: 'OAuth 2.1 — consolidation draft' url: 'https://oauth.net/2.1/' - name: 'OpenID Connect Core 1.0' url: 'https://openid.net/specs/openid-connect-core-1_0.html' - name: 'OAuth — Wikipedia' url: 'https://en.wikipedia.org/wiki/OAuth' cta: title: 'Login social sem a dança de redirects' text: 'O Back4app embrulha o fluxo inteiro: entregue ao SDK os tokens de um provedor e o logInWith os verifica no servidor, cria ou encontra o usuário e emite a sua sessão — com o linkWith resolvendo a vinculação de contas em uma chamada.' linkText: 'Comece grátis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-08-21' translationKey: oauth-2-social-login --- **OAuth 2.0 é um padrão de autorização que permite a um app acessar a conta de um usuário em outro serviço — o login social constrói a autenticação por cima.** Os dois costumam ser explicados em separado, e é assim que a confusão sobrevive: a [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749) define o encanamento (acesso delegado e com escopo, sem compartilhar senhas), o OpenID Connect adiciona a camada de identidade, e o botão de "Entrar com…" é o recurso de produto montado sobre os dois. ## Principais pontos | Pergunta | Resposta | | --- | --- | | OAuth 2.0 | Autorização delegada: tokens com escopo e expiração no lugar de senhas | | A confusão | OAuth responde *o que este app pode acessar* — OIDC responde *quem é este usuário* | | O fluxo moderno | Authorization code + PKCE — os grants implicit e password sumiram no 2.1 | | Os tokens | Access (curto, com escopo) · refresh (rotacionado) · ID (claims de identidade assinados) | | Login social | OIDC em forma de botão: o provedor autentica, seu app recebe claims verificados | ## O fluxo authorization code, passo a passo A dança de redirects por trás de toda tela de consentimento — com os parâmetros que importam: ```text 1 App → provedor /authorize?client_id=…&redirect_uri=…&scope=profile &state=af3G… ← guarda anti-CSRF, conferida na volta &code_challenge=hK9… ← PKCE: hash de um segredo recém-criado 2 Usuário ↔ provedor Faz login LÁ (a senha nunca toca o app) e consente 3 Provedor → app redirect_uri?code=SplxlO…&state=af3G… ← código de uso único 4 App → provedor POST /token { code, code_verifier } ← prova do PKCE Provedor → app { access_token, refresh_token, id_token } 5 App → API Authorization: Bearer ``` Como isso fica quando um backend embrulha o fluxo — tokens do provedor entram, sessão verificada sai: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Social login: the provider's tokens become a user session const user = await Parse.User.logInWith('apple', { authData: { id: appleUserId, token: identityToken }, }); // First login creates the user; later logins match — session token issued // Account linking: attach a second provider to the same user await user.linkWith('facebook', { authData: fbAuthData }); ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // Social login: the provider's tokens become a user session final user = ParseUser.forQuery(); final response = await user.loginWith( 'apple', apple(identityToken, appleUserId), ); // First login creates the user; later logins match — session token issued // Account linking: attach a second provider to the same user await user.linkWith('facebook', facebook(token, fbUserId, expiresAt)); ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // Social login: the provider's tokens become a user session let user = try await User.apple.login( user: appleUserId, identityToken: identityTokenData ) // First login creates the user; later logins match — session token issued // Account linking: attach a second provider to the same user try await user.facebook.link(userId: fbUserId, accessToken: fbAccessToken) ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Social login: the provider's tokens become a user session val authData = mapOf("id" to appleUserId, "token" to identityToken) ParseUser.logInWithInBackground("apple", authData).continueWith { task -> val user = task.result // First login creates the user; later logins match — session token issued // Account linking: attach a second provider to the same user user.linkWithInBackground("facebook", fbAuthData) } ``` ## Os quatro papéis | Papel | Quem é | Em termos de "Entrar com…" | | --- | --- | --- | | Resource owner | O usuário | Você | | Client | O app pedindo acesso | O app que mostra o botão | | Authorization server | Emite códigos e tokens | As páginas de login do provedor de identidade | | Resource server | A API que guarda os dados | A API de perfil/usuário do provedor | ```mermaid flowchart LR accTitle: Fluxo authorization code do OAuth 2.0 com PKCE accDescr: O app cliente redireciona o usuário ao authorization server com um desafio PKCE; o usuário se autentica e consente lá; o servidor redireciona de volta com um código de uso único; o cliente troca código mais verificador PKCE por access, refresh e ID tokens, e então chama o resource server com o access token. U["Usuário
(resource owner)"] -->|"1 · redirecionado com
state + code_challenge"| AS["Authorization server
login + consentimento"] AS -->|"2 · código de uso único"| C["App cliente"] C -->|"3 · code + code_verifier"| AS AS -->|"4 · access · refresh · ID tokens"| C C -->|"5 · Bearer access_token"| RS["Resource server
(API)"] ``` ## Grant types: qual fluxo, e o que o OAuth 2.1 mudou | Grant | Para | Usuário presente? | Status no [OAuth 2.1](https://oauth.net/2.1/) | | --- | --- | --- | --- | | Authorization code + PKCE | Web, mobile, SPA — qualquer coisa com usuário | Sim | **O padrão — PKCE agora obrigatório para todo cliente** | | Client credentials | Máquina a máquina, contas de serviço | Não | Mantido | | Device authorization | TVs, consoles, CLIs | Sim, em um segundo dispositivo | Mantido | | Refresh token | Renovar o acesso em silêncio | Não | Mantido — rotação ou sender-constraining exigidos para clientes públicos | | Implicit | SPAs legadas (tokens em fragmentos de URL) | Sim | **Removido** | | Password (ROPC) | O app coleta a própria senha | Sim | **Removido** — derrota o propósito inteiro | O OAuth 2.1 é consolidação, não revolução: as remoções acima, mais redirect URIs de correspondência exata e a proibição de bearer tokens em query strings — as lições de segurança acumuladas de uma década dobradas de volta em um só documento. Os explicadores por aí em geral não acompanharam; vários ainda ensinam o fluxo implicit sem qualquer ressalva. ## OAuth vs. OpenID Connect: autorização vs. autenticação A frase que todo mundo repete — "OAuth não é autenticação" — merece seu mecanismo, porque é o mecanismo que torna o login ingênuo explorável: | | Access token (OAuth) | ID token (OIDC) | | --- | --- | --- | | Endereçado a | O resource server (API) | **O seu app** (`aud` = seu client ID) | | Prova | Este portador pode acessar estes escopos | Este usuário (`sub`) se autenticou neste emissor (`iss`), agora (`iat`/`exp`), para este login (`nonce`) | | Formato | Muitas vezes opaco para o cliente | [JWT](/glossary/pt/json-web-token-jwt/) assinado que seu app deve validar | | Serve para fazer login? | **Não** — qualquer app autorizado pelo usuário possui um; ele não diz nada sobre quem está presente | Sim — esse é exatamente o seu trabalho | "Login com um access token puro" falha porque access tokens são evidência transferível de *permissão*, não de *presença*: um app malicioso que obteve um token para os próprios fins poderia reapresentá-lo em outro lugar para se passar pelo usuário. O [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html) existe precisamente para fechar essa brecha — os mesmos fluxos, mais uma asserção de identidade criptograficamente vinculada ao seu app. ## Login social: o botão em cima do encanamento Login social é o OIDC embalado como UX: o provedor autentica, seu app recebe claims verificados e cria ou encontra uma conta — nenhuma senha armazenada, nenhum fluxo de redefinição para manter, a MFA do provedor herdada de graça. Os trade-offs de produto merecem números honestos. As alegações de 20–50% de aumento no cadastro são folclore de fornecedor; testes controlados mediram algo mais perto de 3% — ainda que cerca de um terço dos logins de consumo hoje chegue pela via social, sinal claro de que os usuários querem a opção. As práticas que de fato movem a conversão: ofereça **dois ou três provedores** que a sua audiência usa (o "grid de largada" de botões comprovadamente atrapalha), mantenha sempre a alternativa por e-mail, e saiba que redirects de OAuth quebram dentro de WebViews embutidas — uma causa real de falha de cadastro no mobile. Dois fatos específicos de provedor pesam o bastante para serem nomeados: o **Sign in with Apple** emite endereços de relay privado (`…@privaterelay.appleid.com`), então vinculação por e-mail e listas de e-mail precisam esperar aliases opacos — e as regras da App Store exigem que apps que oferecem login de terceiros ofereçam também o da Apple. ## Vinculação de contas e a armadilha do e-mail A mesma pessoa vai chegar por dois provedores, e os dois vão informar `ada@example.com`. A regra que evita a vulnerabilidade clássica: **a identidade se ancora no identificador `sub` estável do provedor, nunca no e-mail sozinho.** E-mails mudam, são reciclados e — a aresta afiada — nem sempre são verificados: uma classe de vulnerabilidades de 2023 mostrou que apps que confiavam em um claim de e-mail não verificado nos tokens de um grande provedor de identidade ficavam abertos a roubo de conta por qualquer um capaz de definir aquele e-mail na própria conta do provedor. Vincule automaticamente só e-mails que o provedor atesta como verificados; caso contrário, peça ao usuário que vincule explicitamente. E planeje a saída: usuários bloqueados em um provedor (acontece sem aviso) perdem todos os apps rio abaixo, a menos que você tenha oferecido um segundo método vinculado — e é por isso que "um método de login por usuário" é um gerador de tickets de suporte fantasiado de simplicidade. ## Casos de uso comuns - **Login em apps de consumo** — o login social canônico: menos atrito, MFA herdada, nenhum banco de senhas para vazar. - **Acesso a APIs de terceiros** — o caso original do OAuth: um app de agenda lendo o seu calendário sem a sua senha. - **Autenticação máquina a máquina** — client credentials entre serviços, sem usuário à vista. - **Identidade multi-provedor** — uma conta, vários métodos de login vinculados, desvinculação e recuperação por usuário. - **Ponte para SSO corporativo** — o mesmo padrão OIDC apontado para um provedor de identidade corporativo em vez de um social. ## Você deveria oferecer login social? Matriz de decisão | Sua situação | Tendência | | --- | --- | | App de consumo, audiência majoritariamente mobile | Sim — 2–3 provedores + alternativa por e-mail | | App iOS oferecendo qualquer login de terceiros | O login da Apple passa a ser obrigatório — planeje para e-mails de relay | | Produto B2B/corporativo | OIDC sim, mas rumo ao [SSO](/glossary/pt/single-sign-on-sso/) corporativo, não ao social | | Dados regulados, ciclo de vida de conta rígido | Cuidado — bloqueio no provedor e prova de identidade precisam de resposta | | MVP precisando de auth esta semana | Sim, via um backend que embrulha os fluxos | | Usuários sem conta nos grandes provedores | E-mail/passwordless primeiro; social como opção | ## Limitações e trade-offs - **Você herda as decisões do provedor.** Telas de consentimento, duração de sessão, recuperação de conta e deprecações acontecem no cronograma dele, não no seu. - **O risco de concentração é real.** Uma queda do provedor ou um bloqueio de conta é uma queda do seu login; métodos vinculados de reserva são a mitigação, não um extra opcional. - **A flexibilidade do OAuth é sua fraqueza histórica.** Um framework cheio de opções convida combinações inseguras — o 2.1 existe porque fluxos implicit, redirects com curinga e refresh tokens sem rotação continuavam indo para produção. - **Fluxos de redirect têm arestas afiadas.** `state` (CSRF), redirect URIs exatas (open redirect e roubo de código) e PKCE (interceptação) estão cada um a um parâmetro esquecido de um incidente. - **Claims sociais são um piso, não um perfil.** Você recebe subject, e-mail, nome — atributos além disso ainda exigem o seu próprio onboarding, e relays de privacidade significam que até o e-mail pode ser um alias. ## OAuth e login social no Back4app O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Os fluxos acima colapsam nas abas de código: o cliente obtém os tokens do provedor nativamente, os entrega ao `logInWith`, e os adaptadores de autenticação do Back4app os verificam no servidor junto ao provedor antes de criar ou encontrar o `User` — as identidades de provedor vivem em blocos `authData` por provedor, ancorados no subject estável, que é a regra de vinculação de contas imposta por construção. O `linkWith` acopla provedores adicionais (ou uma credencial de e-mail) ao mesmo usuário, respondendo ao problema do bloqueio em uma chamada, e o token de sessão que seu app recebe funciona nas APIs REST, GraphQL e Live Query, com [ACLs](/glossary/access-control-lists-acl/) e permissões em nível de classe decidindo o que ele pode tocar. A dança de redirects, a verificação de tokens e os casos-limite de vinculação chegam como comportamento de plataforma — você configura os provedores no painel e entrega o botão.