Conectando os pontos: Uma exploração aprofundada do recurso 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 ID tokens, componentes essenciais para a construção de uma autenticação robusta em sua aplicação. No entanto, questões ainda permanecem em nossa comunidade, com uma pergunta recorrente: "Por que o 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 do blog visa esclarecer a relação entre os indicadores de recursos do OIDC e seu papel na obtenção de tokens de acesso.

Compreendendo o recurso OIDC#

Se você está familiarizado com o protocolo OAuth 2.0, o termo “recurso” deve chamar sua atenção. Como o OIDC é construído em cima do OAuth 2.0, ele herda este mesmo conceito.

Um "recurso" ou "recurso protegido" é uma representação de uma entidade que a aplicação do cliente quer acessar em nome do usuário autenticado. Isto 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 em solicitações para o servidor de autorização. É um valor representado como um URI absoluto, como https://my-company.com/api. Ele age como um identificador para o recurso, potencialmente correspondendo a um local endereçável por rede ou mesmo a um URI único, mas 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 no formato JWT (JSON web token) é emitido apenas quando o parâmetro "recurso" é especificado durante a solicitação do token de acesso, e ele carrega um conjunto de reivindicações, das quais você pode decifrar e validar, por exemplo, para assegurar a integridade do token e as permissões do usuário.

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

Então, a relação se torna clara:

• Especifique o indicador de recurso ao solicitar um token JWT.
• O indicador de recurso se alinha com a reivindicação de token aud.
• Ao fazer solicitações de API, o token de acesso JWT deve ser incluído como o cabeçalho de token do portador. Seu servidor API deve decifrar e validar a reivindicação aud e outras reivindicações relacionadas às permissões para garantir a solicitação da API.
• Cada token de acesso corresponde a um único recurso. Se você tem múltiplos recursos API registrados com diferentes URIs, 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 for especificado ao solicitar o token de acesso, o servidor de autorização assume que é para o endpoint OIDC /userinfo, e assim um token de acesso opaco será emitido que pode ser usado posteriormente pelo cliente para solicitar o perfil do usuário, como o ID do usuário, nome, e-mail, etc., a partir do endpoint userinfo OIDC.

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

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

Em resumo#

Os recursos OIDC definem dados específicos ou serviços que uma aplicação cliente quer acessar em nome do usuário, com os 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 os servidores na verificação das permissões aquando das solicitações do cliente.

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

Esperamos que este post do blog tenha esclarecido quaisquer dúvidas e conectado os pontos para você. Sinta-se à vontade para nos dizer o que pensa.