OpenID Connect: o que é, protocolo de autenticação e autorização

O que é OpenID Connect?

OpenID Connect (OIDC) é um protocolo de autenticação aberto construído como uma extensão sobre o OAuth 2.0. Ele padroniza o que faltava no OAuth 2.0: a verificação de identidade do usuário. Se o OAuth 2.0 responde à pergunta “qual aplicativo tem acesso?”, então o OIDC responde “quem é exatamente este usuário?”.

O protocolo usa um ID Token — um JSON Web Token (JWT) que contém um conjunto de claims: um identificador de assunto único, email, nome, avatar, carimbos de data/hora de emissão e expiração. O aplicativo cliente pode verificar criptograficamente o ID Token — o servidor assina o token usando RS256 ou ES256, e o cliente verifica a assinatura contra a chave pública obtida através do endpoint JWKS.

De acordo com Auth0, 2025, mais de 78% dos aplicativos móveis que usam autenticação de terceiros empregam OIDC através do Google Sign-In ou Sign in with Apple. Isso torna o protocolo o padrão de facto para login social e autenticação empresarial.

Como funciona o OpenID Connect

OpenID Connect define vários fluxos (flows) dependendo do tipo de cliente. Para aplicativos móveis, o padrão é o Authorization Code Flow com Proof Key for Code Exchange (PKCE) — ele fornece segurança mesmo sem um client secret no dispositivo.

Identity Provider e seu papel

Um Identity Provider (IdP) é um servidor que autentica usuários e emite tokens. No ecossistema OIDC, o IdP fornece dois endpoints principais: o Authorization Endpoint para login do usuário e o Token Endpoint para trocar o código por tokens. O cliente descobre os endereços desses endpoints através da Discovery URL — o caminho padrão /.well-known/openid-configuration, que retorna um documento JSON com toda a configuração do provedor.

Cada IdP publica seu JWKS (JSON Web Key Set) — um conjunto de chaves públicas para verificar a assinatura do ID Token. O cliente armazena em cache essas chaves e as usa para verificar cada token recebido sem contatar o servidor.

Authorization Code Flow com PKCE

O Authorization Code Flow é um processo de três etapas. Primeiro, o aplicativo móvel gera um code verifier (uma string aleatória de 43–128 caracteres) e seu hash — o code challenge. O aplicativo abre um navegador ou WebView com uma URL contendo o client_id, redirect_uri, scope (openid profile email) e code challenge. O usuário insere as credenciais na página do IdP e confirma o consentimento. O IdP redireciona o navegador de volta ao aplicativo com um authorization code.

Na segunda etapa, o aplicativo envia o authorization code, code verifier e client_id para o Token Endpoint do servidor. O servidor verifica o code verifier contra o code challenge armazenado e retorna um ID Token, Access Token e opcionalmente um Refresh Token. Na terceira etapa, o aplicativo verifica o ID Token: valida a assinatura contra o JWKS, verifica o issuer (iss), audience (aud) e o tempo de expiração (exp). Se a verificação for bem-sucedida, o usuário é considerado autenticado.

O PKCE (Proof Key for Code Exchange) elimina uma vulnerabilidade inerente ao Authorization Code Flow padrão em clientes públicos. Como um aplicativo móvel não pode armazenar um client secret com segurança, um invasor que intercepte o authorization code poderia trocá-lo por tokens. O code verifier resolve esse problema: mesmo que o código seja interceptado, sem o code verifier original a troca é impossível. As OAuth Security Best Practices (RFC 9700) exigem PKCE para todos os clientes públicos, incluindo aplicativos móveis.

ID Token e Access Token

O OpenID Connect retorna dois tokens fundamentalmente diferentes: o ID Token e o Access Token. O ID Token é sempre um JWT que o cliente pode ler e verificar por conta própria. Ele contém informações do usuário e é usado para autenticação, não para acesso à API.

Estrutura do ID Token

O ID Token consiste em um header, payload e signature, codificados em Base64 e separados por pontos. O header contém alg (algoritmo de assinatura) e kid (identificador da chave). O payload inclui claims obrigatórios: iss (issuer), sub (subject — ID único do usuário), aud (audience — identificador do cliente), exp (expiration), iat (issued at). Claims opcionais incluem name, email, picture, locale.

Exemplo de um payload de ID Token decodificado do Google:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "aud": "my-app-123.apps.googleusercontent.com",
  "exp": 1812345678,
  "iat": 1812342078,
  "name": "Ivan Petrov",
  "email": "ivan@example.com"
}

O Access Token é um token opaco (string arbitrária) ou JWT que o cliente passa nas requisições à API. Ao contrário do ID Token, o access token não foi projetado para ser lido pelo cliente — seu formato e conteúdo são conhecidos apenas pelo servidor de recursos e pelo servidor de autorização. O Access Token tem um scope — uma restrição de permissão — e uma vida útil curta, normalmente de 15–60 minutos.

Diferenças entre OpenID Connect e OAuth 2.0

OAuth 2.0 é uma estrutura de autorização que define como um aplicativo obtém acesso aos recursos do usuário. OpenID Connect é uma extensão que adiciona autenticação a esse processo. A principal diferença: o OAuth 2.0 não define um formato de token e não fornece ao aplicativo uma maneira de saber quem exatamente fez a solicitação.

Quando escolher o OpenID Connect

O OpenID Connect é necessário quando o aplicativo precisa identificar o usuário, não apenas obter acesso aos seus dados. Se você usa “Fazer login com Google” ou “Fazer login com Apple” — isso é OIDC. Se seu aplicativo chama uma API de terceiros em nome do usuário sem precisar saber sua identidade — OAuth 2.0 puro é suficiente. Para sistemas empresariais com Single Sign-On (SSO), a escolha é clara: apenas OpenID Connect, pois ele fornece logout padronizado e gerenciamento de sessão.

Implementação do OpenID Connect em aplicativos móveis

A integração do OpenID Connect em um aplicativo móvel requer a escolha da biblioteca certa e a configuração correta do fluxo. Para Android, use o gerenciador de credenciais (AndroidX Credentials) ou a biblioteca AppAuth. Para iOS, use o framework AuthenticationServices com ASWebAuthenticationSession.

Exemplo de código em Kotlin (Android)

Abaixo está um exemplo de início do Authorization Code Flow usando a biblioteca AppAuth-Android. O aplicativo cria uma solicitação de autorização, abre um navegador para login do usuário e processa o callback com os tokens.

val authRequest = AuthorizationRequest.Builder(
    serviceConfig,
    clientId,
    "code",
    Uri.parse("com.example.app:/oauth")
)
.setScope("openid profile email")
.build()

val authService = AuthorizationService(this)
val intent = authService.getAuthorizationRequestIntent(authRequest)
startActivityForResult(intent, REQUEST_CODE)

override fun onActivityResult(
    requestCode: Int,
    resultCode: Int,
    data: Intent?
) {
    if (requestCode == REQUEST_CODE) {
        val response = AuthorizationResponse.fromIntent(data)
        if (response?.authorizationCode != null) {
            exchangeCodeForTokens(response.authorizationCode)
        }
    }
}

Exemplo de código em Swift (iOS)

O ASWebAuthenticationSession da Apple fornece um navegador integrado para o fluxo OIDC com suporte SSO através do iCloud Keychain. A sessão é iniciada com a URL de autorização, e o callback é tratado através de um completion handler.

Ao escolher uma biblioteca para OpenID Connect, considere o suporte PKCE integrado: AppAuth-Android e AppAuth-iOS suportam PKCE por padrão. O Firebase Authentication usa OIDC internamente para Google Sign-In, Sign in with Apple e Microsoft — o desenvolvedor não precisa implementar o fluxo manualmente. Para sistemas empresariais com um IdP personalizado (por exemplo, Keycloak ou Okta), o AppAuth continua sendo a escolha padrão com controle total sobre configuração e tratamento de erros.

let authURL = URL("https://accounts.google.com/o/oauth2/v2/auth")!
let callbackURL = URL("com.example.app://oauth")!

let session = ASWebAuthenticationSession(
    url: authURL,
    callbackURLScheme: callbackURL.scheme!
) { url, error in
    guard let url = url else { return }
    let components = URLComponents(url: url)
    let code = components?.queryItems?.first(where: { $0.name == "code" })?.value
    if let code = code { exchangeCode(code) }
}
session.start()