OAuth 2.0: o que é e como funciona o protocolo de autorização

O que é OAuth 2.0?

OAuth 2.0 é um protocolo de autorização definido na IETF RFC 6749 que permite a aplicações de terceiros obter acesso limitado aos recursos de um utilizador sem revelar o seu nome de utilizador e palavra-passe. O protocolo resolve um problema fundamental do modelo de palavra-passe: uma aplicação a quem confia a sua palavra-passe obtém acesso ilimitado a todos os dados da conta. O OAuth 2.0 substitui esta abordagem emitindo um token temporário com um âmbito de acesso explicitamente limitado.

A arquitetura do OAuth 2.0 é a autorização delegada. O utilizador (Resource Owner) autoriza uma aplicação (Client) a aceder aos seus dados armazenados num servidor de recursos (Resource Server) através de um intermediário: o servidor de autorização (Authorization Server). O servidor de autorização emite um Access Token, uma cadeia criptográfica que a aplicação apresenta ao servidor de recursos para aceder aos dados. Uma diferença importante entre OAuth 2.0 e SAML ou OpenID Connect: o OAuth 2.0 resolve a tarefa de autorização (o que é permitido), não a autenticação (quem é o utilizador). Para autenticação sobre OAuth 2.0, é construído o protocolo OpenID Connect (OIDC).

O protocolo é suportado por todas as principais plataformas. O Google utiliza OAuth 2.0 para aceder às Google APIs (Gmail, Drive, Calendar), o Facebook para a Graph API, a Apple para o Sign in with Apple (ASAuthorizationAppleIDProvider) e o GitHub para acesso a repositórios. No contexto do desenvolvimento móvel, o OAuth 2.0 é o mecanismo padrão para integrar serviços de terceiros: início de sessão através de redes sociais, acesso a armazenamento na nuvem e publicação de conteúdo em nome do utilizador.

Funções e componentes do OAuth 2.0

O protocolo OAuth 2.0 define quatro funções cuja interação forma o ciclo completo de autorização. Compreender cada função é essencial para implementar corretamente o protocolo numa aplicação móvel.

As quatro funções do protocolo

As entidades-chave do protocolo são o Access Token, o Refresh Token e o Authorization Code. O Access Token é um token de curta duração (geralmente 15–60 minutos) apresentado ao servidor de recursos a cada pedido de dados. O Refresh Token é um token de longa duração (dias ou semanas) usado para obter um novo Access Token sem que o utilizador tenha de fazer login novamente. O Authorization Code é um código temporário emitido após a autorização do utilizador e trocado por um Access Token e Refresh Token.

Grant Types: cenários de autorização

O OAuth 2.0 define vários Grant Types, cenários de obtenção de tokens, cada um concebido para um tipo específico de cliente e contexto de segurança. Escolher o Grant Type correto é uma decisão arquitetónica crítica ao projetar a autorização numa aplicação móvel.

Os principais Grant Types são: Authorization Code (o mais seguro para aplicações móveis e web com componente de servidor), Authorization Code com PKCE (Proof Key for Code Exchange, para aplicações móveis e SPA sem backend de servidor), Client Credentials (para autenticação servidor a servidor sem participação do utilizador) e Resource Owner Password Credentials (obsoleto: transmite a palavra-passe diretamente). O PKCE é uma extensão obrigatória para clientes públicos (aplicações móveis, SPA) de acordo com as recomendações do OAuth Security BCP (RFC 9700).

Principais Grant Types

• Authorization Code + PKCE é o Grant Type recomendado para aplicações móveis nativas. O cliente gera um code_verifier criptográfico, calcula um code_challenge (hash SHA-256) e o servidor verifica a correspondência ao trocar o código por um token. Isto evita a interceção do authorization code entre a aplicação e o servidor
• Client Credentials é utilizado para autorização machine-to-machine onde o cliente é conhecido e autenticado. A aplicação obtém um token usando o seu client_id e client_secret. Não requer participação do utilizador. Cenário típico: uma aplicação de servidor acede a uma API para processamento de dados em lote
• Device Authorization Grant é para dispositivos sem navegador (Smart TV, IoT). O utilizador segue um link noutro dispositivo e introduz um código. Utilizado, por exemplo, ao autorizar o Netflix numa televisão através de um smartphone
• Resource Owner Password Credentials é um Grant Type obsoleto proibido pelo OAuth Security BCP. A palavra-passe é transmitida diretamente ao cliente, violando o princípio de autenticação de conhecimento zero. Utilizado apenas para migração de sistemas legados

Authorization Code Flow com PKCE para aplicações móveis

Authorization Code Flow com PKCE é a configuração recomendada do OAuth 2.0 para aplicações móveis nativas. O PKCE (Proof Key for Code Exchange) adiciona uma camada extra de proteção que previne ataques de interceção do authorization code. O protocolo é descrito na IETF RFC 7636.

Sequência passo a passo do PKCE

A sequência de passos: (1) o cliente gera um code_verifier aleatório (uma string de 43–128 caracteres usando apenas caracteres não reservados), (2) o cliente calcula code_challenge = SHA-256(code_verifier), (3) o cliente abre um navegador para autorização do utilizador no Authorization Server, passando o code_challenge, (4) após autorização bem-sucedida, o servidor devolve o authorization code à aplicação através de um esquema URI personalizado (deep link da aplicação), (5) o cliente envia o authorization code + code_verifier ao servidor, (6) o servidor verifica SHA-256(code_verifier) === code_challenge e emite um Access Token + Refresh Token.

A vantagem do PKCE é que mesmo que um atacante intercete o authorization code no esquema URI, não consegue trocá-lo por um token sem o code_verifier, que só o cliente legítimo conhece. Em aplicações móveis, para abrir o navegador devem ser usados Chrome Custom Tabs (Android) ou ASWebAuthenticationSession (iOS); isto garante que o navegador do sistema não tem acesso ao code_verifier a partir da memória da aplicação.

Implementação do OAuth 2.0 no Android via AppAuth

AppAuth é a implementação de referência do OAuth 2.0 e OpenID Connect para aplicações nativas, recomendada pela IETF. A biblioteca suporta PKCE, Chrome Custom Tabs, esquemas URI personalizados para devolver o authorization code e atualização automática de tokens. O AppAuth para Android está disponível através da dependência `net.openid:appauth:0.11.1`.

val serviceConfig = AuthorizationServiceConfiguration.fromUrl(
    Uri.parse("https://accounts.google.com/.well-known/openid-configuration")
)

val request = AuthorizationRequest.Builder(
    serviceConfig,
    "CLIENT_ID.apps.googleusercontent.com",
    ResponseTypeValues.CODE,
    Uri.parse("com.example.app:/oauth2callback")
)
.setScope("openid profile email")
.setCodeVerifier(
    CodeVerifierUtil.generateRandomCodeVerifier()
)
.build()

val authService = AuthorizationService(context)
val intent = authService.getAuthorizationRequestIntent(request)

// Iniciar Chrome Custom Tab para autorização
startActivityForResult(intent, REQUEST_CODE_AUTH)

Após receber o authorization code (onActivityResult), a aplicação troca-o por um Access Token e Refresh Token através de um TokenRequest. Os tokens são guardados em SharedPreferences com encriptação via EncryptedSharedPreferences (Android Security Crypto). O Refresh Token deve ser armazenado no KeyStore, um armazém de chaves baseado em hardware inacessível a outras aplicações. Cada vez que o Access Token expira, a aplicação utiliza o Refresh Token para obter um novo: o utilizador não precisa de se autenticar novamente.

// Trocar authorization code por tokens
val data = intent?.data ?: return
val resp = AuthorizationResponse.fromIntent(data)
val exchangeReq = resp?.createTokenExchangeRequest()
    ?: return

authService.performTokenRequest(
    exchangeReq,
    ClientAuthentication.none()
) { tokenResp, ex ->
    if (tokenResp != null) {
        // Access Token e Refresh Token recebidos
        val accessToken = tokenResp.accessToken
        val refreshToken = tokenResp.refreshToken
        // Guardar em EncryptedSharedPreferences
        saveTokens(accessToken, refreshToken)
    }
}

O código acima demonstra o fluxo completo do OAuth 2.0 com PKCE: criação da configuração do servidor através do OpenID Connect Discovery, geração de um pedido de autorização com code_verifier, lançamento do Chrome Custom Tab, receção do authorization code através de um esquema URI personalizado e troca do código por tokens através de um Token Request. É importante lidar com a expiração do Access Token: ao receber uma resposta HTTP 401 do Resource Server, a aplicação deve usar o Refresh Token para obter um novo Access Token e reexecutar o pedido.

Segurança do OAuth 2.0: ataques típicos e proteção

OAuth 2.0 é um protocolo complexo com múltiplos vetores de ataque. O IETF Security BCP (RFC 9700) descreve mais de 20 classes de vulnerabilidades do OAuth 2.0. Para aplicações móveis, as mais críticas são: interceção do authorization code através de esquemas URI personalizados, ataques CSRF em endpoints de callback, roubo do Refresh Token de armazenamento inseguro e suplantação do cliente através de interceção de intents.

A proteção contra estes ataques inclui medidas obrigatórias: (1) PKCE com code_challenge S256: previne a interceção do authorization code mesmo que o esquema URI seja intercetado; (2) uso de um parâmetro nonce ou state para prevenir CSRF: o servidor verifica que o authorization code corresponde ao pedido original; (3) armazenamento do Refresh Token apenas no KeyStore (Android) ou Keychain (iOS), nunca em SharedPreferences ou UserDefaults; (4) uso de TLS com Certificate Pinning para proteção contra MITM na camada de transporte; (5) validação do redirect_uri: o servidor de autorização deve validar rigorosamente a correspondência com o URI registado.

Recomendações adicionais da IETF: as aplicações móveis devem usar AppAuth ou bibliotecas semelhantes que tenham passado por auditorias de segurança; não confiar em WebView para OAuth (o WebView não isola os dados da aplicação principal); implementar rotação automática do Refresh Token (cada Refresh Token pode ser usado apenas uma vez); adicionar Certificate Pinning através do TrustManager para Android e URLSession para iOS. O OpenID Connect Discovery (endpoint well-known) ajuda a determinar automaticamente os endpoints corretos do servidor de autorização e evitar redirecionamentos para páginas de phishing.