Compreender tokens de acesso, tokens de atualização e tokens de ID no protocolo OpenID Connect (OIDC)
O Protocolo OpenID Connect (OIDC) tornou-se um padrão amplamente adotado para a gestão de identidades. Mas será que compreendes realmente as funções e os atributos destes tokens?
CharlesDeveloper
Pare de perder semanas com autenticação de utilizadores
Lance aplicações seguras mais rapidamente com o Logto. Integre a autenticação de utilizadores em minutos e concentre-se no seu produto principal.
O Protocolo OpenID Connect, também conhecido como OIDC, tornou-se um padrão amplamente adotado para fornecer uma estrutura fundamental para a gestão de identidades.
É uma camada de autenticação construída com base no conhecido protocolo OAuth 2.0. Enquanto o OAuth 2.0 é apenas para autorização de recursos, o OIDC é o protocolo que padroniza e reforça a autenticação do cliente, com a ajuda do novo token de ID introduzido.
Espera... Tu podes já ter ouvido falar de tokens de acesso e tokens de atualização na era do OAuth, e agora surge este novo conceito no OIDC? Será que compreendes verdadeiramente as diferenças entre estes tokens?
O que são tokens de acesso, tokens de atualização e tokens de ID no OIDC?#
Vamos começar por um cenário prático.
Imagina que estás a desenvolver uma típica aplicação cliente-servidor, e que comunicam entre si através de APIs RESTful. Queres manter a maioria das tuas APIs privadas, permitindo apenas que clientes autorizados acedam. Precisarás de um mecanismo para autenticar o cliente e autorizar os pedidos de API para o teu servidor.
Idealmente, as tuas APIs RESTful devem ser sem estado, o que significa que o servidor não deve armazenar qualquer informação de sessão do cliente. Sempre que um pedido válido é feito, o servidor deve simplesmente responder com os dados solicitados. É aqui que os tokens entram em jogo. Então, que tipo de token deverás usar neste caso?
Tokens de acesso são usados para proteger as tuas APIs#
No OAuth 2.0 e OIDC, cada API protegida é tratada como um recurso. O token de acesso é precisamente o token que o cliente transmite ao servidor quando solicita um recurso de API, normalmente através do cabeçalho de pedido e no formato JWT.
No lado do servidor, sempre que chega um pedido, o servidor só precisa de validar se o pedido de entrada transporta um token de acesso válido. O processo de validação geralmente inclui a decodificação do token JWT, a verificação da assinatura e do tempo de expiração, bem como a declaração do escopo para garantir que o cliente tem as permissões necessárias.
No entanto, podes perguntar: Se a minha aplicação cliente pode ter um token de acesso válido após um login bem-sucedido e usar o token de acesso para solicitar APIs do servidor, isso não é suficiente? Porque é que preciso dos outros tokens?
De facto, é uma pergunta válida, e vamos explicá-la passo a passo.
Embora tecnicamente os tokens de acesso atendam aos requisitos mínimos para fazer o sistema funcionar, no entanto, devido a preocupações de segurança, a validade dos tokens de acesso é geralmente muito curta (normalmente uma hora). Então imagina, se apenas tivéssemos tokens de acesso, os utilizadores finais teriam de se reautenticar sempre que o token de acesso expirasse. Para aplicações modernas de página única (SPAs) e especialmente para aplicações móveis, sair com frequência é uma experiência de utilizador bastante penosa, mesmo que estejamos apenas a tentar proteger a segurança do utilizador.
Por conseguinte, precisamos de um equilíbrio entre segurança do token e conveniência do utilizador. É por isso que os tokens de atualização foram introduzidos.
Porque os tokens de atualização podem ter uma vida útil mais longa?#
Os tokens de acesso são usados para aceder a recursos de API, portanto, a sua natureza de curta duração ajuda a mitigar o risco de serem vazados ou comprometidos. Por outro lado, como os tokens de atualização são usados apenas para trocar por novos tokens de acesso, eles não são usados com tanta frequência como os tokens de acesso e, portanto, o risco de exposição é reduzido. Portanto, ter um período de validade mais longo é considerado aceitável para os tokens de atualização.
Dado que o token de atualização também é armazenado do lado do cliente, garantir que não seja comprometido é um desafio, especialmente para clientes públicos, como aplicações web de página única (SPA) e aplicações móveis.
No Logto, os tokens de atualização têm um mecanismo de rotação automático habilitado por defeito, o que significa que o servidor de autorização irá emitir um novo token de atualização assim que este atender aos critérios:
Aplicações de página única: Reconhecidas como clientes não restringidos pelo remetente, essas aplicações exigem rotação de token de atualização. O tempo de vida (TTL) do token de atualização não pode ser especificado.
Aplicações nativas e aplicações web tradicionais: A rotação de token de atualização é inerentemente habilitada, renovando-se automaticamente ao atingir 70% do seu TTL. Saiba mais sobre rotação de token de atualização no Logto
Embora ainda tenhas a opção de desativar a rotação do token de atualização na página de detalhes da aplicação no console de administração, é fortemente recomendado manter esta medida de proteção.
O token de ID é uma característica única do OIDC que fornece informações de identidade sobre o utilizador autenticado.
Enquanto os tokens de acesso são usados para aceder a recursos protegidos e os tokens de atualização são usados para obter novos tokens de acesso, os tokens de ID são tipicamente usados para armazenar em cache informações do utilizador do lado do cliente, reduzindo a necessidade de fazer pedidos adicionais ao servidor de autorização por dados do utilizador. Na maioria dos casos, é até seguro dizer que, ter o token de ID é equivalente a o utilizador estar autenticado.
Usa HTTPS: Usa sempre HTTPS para proteger a comunicação entre o cliente e o servidor de autorização. Isso impede que partes não autorizadas intercepem e roubem tokens.
Define o tempo de expiração adequado para o token: Tokens de acesso devem ter uma vida útil curta para minimizar o risco de exposição. Tokens de atualização podem ter um período de validade mais longo.
Habilita a rotação de token de atualização: Implementa a rotação de token de atualização para mitigar o risco de vazamento de token de atualização.
Usa controle de acesso granular: Usa escopos granulares para limitar as permissões dos tokens de acesso. Solicita apenas as permissões necessárias para a aplicação cliente. Evita usar "todos" ou "admin" escopos para contornar a maioria das verificações de permissão, a menos que seja absolutamente necessário.
Recapitulação: Principais diferenças dos tokens de acesso, tokens de atualização e tokens de ID no OIDC#
No protocolo OIDC, tokens de atualização, tokens de acesso e tokens de ID trabalham juntos para fornecer uma autenticação de utilizador segura e contínua.
Tokens de acesso fornecem autorização para aceder a recursos protegidos.
Tokens de atualização eliminam a intervenção do utilizador para novos tokens de acesso.
Tokens de ID fornecem informações de utilizador armazenadas em cache no cliente, melhorando o desempenho.
Compreender o papel e a importância destes tokens é crucial para os desenvolvedores que implementam autenticação OIDC nas suas aplicações.
