Conectando os pontos: Uma exploração aprofundada dos recursos OIDC e seus tokens de acesso JWT

Contexto#

Em uma sessão anterior, nós fornecemos uma introdução ao Protocolo OpenID Connect (OIDC), tokens de atualização, tokens de acesso e tokens ID, componentes essenciais para a construção de autenticação robusta em seu aplicativo. No entanto, perguntas ainda persistem em nossa comunidade, com uma pergunta recorrente: "Por que meu token de acesso não é um JWT?”

Para aqueles que são novos nos conceitos, ou mesmo para aqueles que precisam de uma reciclagem, este post no blog visa esclarecer a relação entre os indicadores de recursos OIDC e seu papel na obtenção de tokens de acesso.

Entendendo o recurso OIDC#

Se você está familiarizado com o protocolo OAuth 2.0, o termo “recurso” deve soar familiar. Como OIDC foi construído sobre o OAuth 2.0, herda este mesmo conceito.

Um "recurso" ou "recurso protegido" é uma representação de uma entidade que o aplicativo cliente deseja acessar em nome do usuário autenticado. Isso pode ser informações do usuário, APIs do servidor, ou qualquer outro dado autorizado pelo seu servidor.

De acordo com o protocolo, o recurso é um parâmetro nas solicitações para o servidor de autorização. É um valor representado como um URI absoluto, como https://minha-empresa.com/api. Age como um identificador para o recurso, potencialmente correspondendo a um local acessível pela rede ou até mesmo a um URI único, porém fictício.

No Logto, você pode criar um "recurso API" através da página "Console de administração → recursos API". Você pode se referir a esta documentação para mais detalhes.

Token de acesso JWT#

O token de acesso formato JWT é emitido apenas quando o parâmetro "recurso" é especificado durante a solicitação do token de acesso, e ele carrega um conjunto de reivindicações, que você pode descriptografar e validar, por exemplo, para garantir a integridade do token e as permissões do usuário.

Este "recurso" então se torna uma das reivindicações do token aud no JWT, indicando o público pretendido para o token. Veja RFC-7519.

Portanto, a relação fica clara:

• Especifique o indicador de recurso ao solicitar um token JWT.
• O indicador de recurso se alinha com a reivindicação do token aud.
• Ao fazer solicitações de API, o token de acesso JWT deve ser incluído como o cabeçalho do token do portador. Seu servidor de API deve descriptografar e validar a reivindicação aud e outras reivindicações relacionadas à permissão para proteger a solicitação de API.
• Cada token de acesso corresponde a um único recurso. Se você tiver vários recursos de API registrados com URIs diferentes, solicite tokens de acesso distintos para cada um.

🤔 Mas e se o cliente não especificar o recurso ao solicitar o token de acesso?

Token de acesso opaco#

No caso do Logto, se o indicador de recurso não é especificado ao solicitar o token de acesso, o servidor de autorização supõe que é para o endpoint OIDC /userinfo, e assim um token de acesso opaco será emitido que pode ser usado mais tarde pelo cliente para solicitar o perfil do usuário, como ID do usuário, nome, email, etc., a partir do endpoint OIDC userinfo.

Em qualquer SDK Logto, você pode obter tal token se você chamar getAccessToken() ou solicitar diretamente o endpoint do token OIDC sem especificar o parâmetro recurso.

Note-se que esse token de acesso opaco não é adequado para suas próprias solicitações de recursos de API, uma vez que não há maneira de verificar sem solicitar o servidor OIDC.

Em resumo#

Recursos OIDC definem dados específicos ou serviços que um aplicativo cliente deseja acessar em nome do usuário, com tokens de acesso JWT servindo como o meio seguro para este acesso. A reivindicação "aud" nos tokens de acesso JWT se alinha com o indicador de recurso, ajudando servidores a verificar permissões em solicitações de clientes.

No Logto, o token de acesso opaco é apenas para buscar informações do perfil do usuário a partir do endpoint OIDC userinfo, enquanto os clientes podem solicitar múltiplos tokens de acesso, cada um dedicado a um recurso específico.

Esperamos que este post no blog elimine quaisquer dúvidas e conecte os pontos para você. Sinta-se à vontade para nos dizer o que você pensa.