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.
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.
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.
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:
aud.aud e outras reivindicações relacionadas à permissão para proteger a solicitação de API.🤔 Mas e se o cliente não especificar o recurso ao solicitar o token de acesso?
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.
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.