OpenID Notas de implementação do Connect

Editar online

IBM® Verify continua a realizar melhorias de segurança na implementação do OpenID Connect, seguindo as melhores práticas de segurança. A compatibilidade com as versões anteriores será mantida na medida do possível, mas você precisará alterar alguns itens para melhorar a segurança.

Alterações na implementação do Connect d OpenID

  • Algumas mensagens de erro podem ser atualizadas, mas o ID da mensagem permanece o mesmo. Se você tiver algum processo que inclua lógica para ler mensagens de resposta, use o ID da mensagem.
  • Quando o endpoint de autorização é acessado para obter um código de autorização ou tokens, ele pode redirecionar o usuário para o login ou para a autenticação multifatorial. Em um navegador, essa ação resulta em alguns redirecionamentos automáticos. Se a sua automação de testes for baseada nesse fluxo, certifique-se de seguir automaticamente os redirecionamentos também.
  • No caso de endpoints que retornam um escopo, não retornar escopos ou retornar uma string vazia para os escopos é tratado da mesma forma.
  • Uma barra (/) em uma string JSON pode não estar escapada. Certifique-se de que seu analisador JSON seja compatível com ambos.
  • Os direitos de API não aparecem mais no prompt de consentimento do usuário. Os direitos de acesso à API continuam sendo concedidos aos tokens gerados para esse cliente.
  • A especificação permite o uso do http esquema no redirect_uri somente se o hostname for localhost ou os literais de loopback IP. Consulte OpenID Connect Core 1.0: Seção 3.1.2.1. Solicitação de autenticação.
  • Nem sempre se espera que os parâmetros de consulta estejam na mesma ordem. Ao processar parâmetros de consulta, use a biblioteca adequada ou disponha de um mecanismo robusto regex capaz de identificar o parâmetro independentemente da ordem.

Alterações futuras na implementação do OpenID Connect

Não é necessário fazer nenhuma alteração imediata nos itens a seguir. No entanto, é altamente recomendável que você altere esses itens para garantir que sua implementação do OpenID Connect siga as melhores práticas e esteja preparada para futuras mudanças.
  • Em geral, é mais seguro que as solicitações POST incluam os parâmetros no corpo da solicitação, em vez de nos parâmetros de consulta.
  • O nonce parâmetro deve ser um valor aleatório do ponto de vista criptográfico para que não possa ser adivinhado por invasores. Certifique-se de que seja suficientemente longa e aleatória. Consulte as notas de implementação do Nonce. Recomenda-se um mínimo de 8 caracteres.
  • O servidor de autorização (IBM Verify) gera um código de autorização e tokens que podem ter qualquer comprimento, o que poderá mudar no futuro por motivos de segurança. Ao armazenar os tokens, reserve pelo menos 1024 caracteres para o comprimento do token. O tamanho dos tokens no formato JWT, como o token de identificação ou o token de acesso no formato JWT, depende do conteúdo do JWT. O conteúdo do JWT é expandido à medida que mais atributos são mapeados para ele.
  • O tipo de token para tokens de portador não diferencia maiúsculas de minúsculas; por exemplo, "Bearer" ou "bearer". Não utilize nenhuma validação que distinga maiúsculas de minúsculas para este valor.
  • Quando o fluxo do token de atualização é executado, os novos tokens de identificação não contêm o nonce original. O nonce token retornado pelo fluxo original é usado para mitigar ataques de repetição em solicitações de autorização, e essa mitigação não é necessária para solicitações de token subsequentes no fluxo de atualização de token.
  • Assim como nonce, o verificador de código PKCE precisa ser um valor aleatório do ponto de vista criptográfico e impossível de ser adivinhado. As especificações exigem que o código de verificação tenha, no mínimo, 43 caracteres. Consulte a RFC 7636.
  • Use o state parâmetro para impedir a falsificação de solicitações entre sites, definindo-o como um valor não adivinhável que possa ser validado. Por exemplo, gere um hash do cookie de sessão usado para autenticar o agente do usuário. Consulte a RFC 6749. Recomenda-se um mínimo de 8 caracteres.
  • O valor da aud audiência pode ser uma sequência de caracteres ou uma matriz. Em particular, se houver apenas um valor para o público, ele pode ser uma sequência de caracteres ou uma matriz contendo uma sequência de caracteres.
  • O tipo de concessão de credenciais do cliente destina-se a gerar tokens de acesso para o acesso entre máquinas. Não espere que esse tipo de concessão gere um token de identificação nem utilize o token de acesso para acessar o userinfo ponto de extremidade.
  • O typ parâmetro de cabeçalho (tipo) no token de identificação é opcional. A parte confiável não deve esperar um typ parâmetro de cabeçalho no token de identificação.