Skip to main content

OAuth 2.0 Authorization Code Flow with PKCE

Introdução

OAuth 2.0 é um protocolo de autorização padrão da indústria que permite maior controle sobre o escopo de uma aplicação e fluxos de autorização entre múltiplos dispositivos. O OAuth 2.0 permite escolher escopos específicos e granulares que concedem permissões específicas em nome de um usuário. Para habilitar OAuth 2.0 no seu App, você deve habilitá-lo nas configurações de autenticação do App, na seção App settings do Developer Console.

Por quanto tempo minhas credenciais permanecem válidas?

Por padrão, o access token que você cria via Authorization Code Flow com PKCE só permanece válido por duas horas, a menos que você tenha usado o escopo offline.access.

Refresh tokens

Refresh tokens permitem que uma aplicação obtenha um novo access token sem solicitar o usuário, via fluxo de refresh token. Se o escopo offline.access for aplicado, um refresh token OAuth 2.0 será emitido. Com esse refresh token, você obtém um access token. Se esse escopo não for passado, não geraremos um refresh token. Um exemplo da solicitação que você faria para usar um refresh token e obter um novo access token é o seguinte:

Configurações do App

Você pode selecionar as configurações de autenticação do seu App como OAuth 1.0a ou OAuth 2.0. Também é possível habilitar um App para acessar tanto OAuth 1.0a quanto OAuth 2.0. OAuth 2.0 pode ser usado apenas com a X API v2. Se você selecionou OAuth 2.0, poderá ver um Client ID na seção Keys and Tokens do seu App.

Confidential clients

Confidential clients podem manter credenciais de forma segura, sem expô-las a partes não autorizadas, e se autenticar com segurança no authorization server, mantendo seu client secret protegido. Public clients, como aqueles que normalmente rodam em um navegador ou em um dispositivo móvel, não conseguem usar seus client secrets. Se você selecionar um tipo de App que seja um confidential client, receberá um client secret. Se você selecionou um tipo de client que é confidential client no Developer Console, também poderá ver um Client Secret. Suas opções são Native App, Single page App, Web App, Automated App ou bot. Native App e Single page App são public clients, e Web App e Automated App ou bots são confidential clients. Você não precisa do client id para confidential clients com um header Authorization válido. Ainda é necessário incluir o Client Id no body para as solicitações com um public client.

Escopos

Escopos permitem definir acesso granular ao seu App, para que ele tenha apenas as permissões de que precisa. Para saber mais sobre quais escopos mapeiam para quais endpoints, veja nosso guia de mapeamento de autenticação.

Rate limits

Na maioria dos casos, os rate limits são os mesmos da autenticação com OAuth 1.0a, com exceção de Tweets lookup e Users lookup. Estamos aumentando o limite por App de 300 para 900 solicitações por 15 minutos ao usar OAuth 2.0 para Tweet lookup e user lookup. Para saber mais, confira nossa documentação sobre rate limits.

Grant types

Fornecemos apenas authorization code com PKCE e refresh token como grant types suportados neste lançamento inicial. Podemos fornecer outros grant types no futuro.

Fluxo OAuth 2.0

O OAuth 2.0 usa um fluxo semelhante ao que utilizamos atualmente para OAuth 1.0a. Você pode ver um diagrama e uma explicação detalhada em nossa documentação sobre este assunto.

Glossário

Parâmetros

Para construir uma authorize URL OAuth 2.0, você precisará garantir que os seguintes parâmetros estejam na URL de autorização.

Authorize URL

Com OAuth 2.0, você cria uma authorize URL que pode usar para permitir que um usuário se autentique via um fluxo de autenticação, semelhante ao “Sign In” com X. Um exemplo da URL que você cria é o seguinte:
Você precisará ter a codificação correta para essa URL funcionar; consulte nossa documentação sobre percent encoding.