Validação de Token

Por que validamos tokens? Quando seu aplicativo web verifica as credenciais diretamente, ele verifica se o nome de usuário e a senha apresentados correspondem ao que você mantém. Ao usar a identidade baseada em reivindicações, você está terceirizando esse trabalho para um provedor de identidades.

A responsabilidade muda da verificação de credenciais brutas para a verificação de que o solicitante passou por seu provedor de identidades preferencial e foi autenticado com sucesso. O provedor de identidades representa a autenticação bem-sucedida emitindo um token. Antes de usar as informações ou confiar nelas como uma afirmação de que o usuário foi autenticado, você deve validá-las.

OpenID Documento de Descoberta

O protocolo OpenID Connect 1.0 é uma camada de identidade simples no topo do protocolo OAuth 2.0 que requer o uso de vários pontos finais para autenticar usuários e para solicitar recursos que incluam informações do usuário, tokens e chaves públicas. Para ajudar a descobrir quais são esses pontos finais que você precisa usar, o OpenID Connect permite que você use um documento de descoberta, que é um documento JSON encontrado em um local bem conhecido. Este documento de descoberta contém pares de chave/valor que fornecem detalhes sobre a configuração do provedor do OpenID Connect, incluindo os URIs dos pontos finais de autorização, token, informações do usuário e chaves públicas. Você pode recuperar o documento de descoberta de um serviço OpenID Connect do domínio de identidades do IAM em: https://<domainURL>/.well-known/openid-configuration.

Consulte os documentos de Descoberta do Oracle Identity Cloud Service OpenID.

Validando Tokens de Identidade

Um Token de Identidade (ID) é um token independente e protegido pela integridade (no formato JSON Web Token) que contém reivindicações sobre o usuário final. Representa a sessão de um usuário autenticado. Portanto, o token deve ser validado para que um aplicativo possa confiar no conteúdo do Token de ID. Por exemplo, se um invasor mal-intencionado repetir o Token de ID de um usuário que ele havia capturado anteriormente, o aplicativo deverá detectar que o token foi repetido ou foi usado depois que ele expirou e negar a autenticação.

O Token de ID é definido no padrão do OpenID Connect e é a extensão principal que o OpenID Connect faz para o OAuth 2.0 para ativar a autenticação. Tokens de ID são sensíveis e podem ser mal utilizados se interceptados. Certifique-se de que esses tokens sejam tratados com segurança enviando-os somente via HTTPS e somente usando dados POST ou nos cabeçalhos de solicitação. Se você armazená-los em seu servidor, você também deve armazená-los com segurança.
  1. Verifique se o valor da reivindicação de público (aud) contém o valor client_id do aplicativo. A reivindicação aud (público) pode conter um array com mais de um elemento. O Token de ID deverá ser rejeitado se o token de ID não listar o cliente como um público-alvo válido ou se ele contiver públicos-alvo adicionais que não são confiáveis pelo cliente.

  2. Verifique se o horário atual é anterior ao horário representado pela reivindicação de tempo de expiração (exp).

  3. Verifique se o Token de ID está devidamente assinado pelo emissor. Os tokens emitidos pelo domínio de identidades do IAM são assinados usando um dos certificados encontrados no URI especificado no campo jwks_uri do documento de descoberta.
    • Recupere o certificado público do tenant no ponto final SigningCert/jwk (por exemplo, https://acme.identity.oraclecloud.com/admin/v1/SigningCert/jwk).

      Observação

      Como os domínios de identidades alteram as chaves públicas com pouca frequência, você pode armazenar em cache as chaves públicas e, na grande maioria dos casos, executar com eficiência a validação local. Isso requer recuperar e analisar certificados e fazer as chamadas de criptografia apropriadas para verificar a assinatura:
    • Use qualquer biblioteca JWT disponível para validar, por exemplo, a Biblioteca JWT Nimbus do Connect2id para Java. Consulte JWT para obter uma lista de bibliotecas disponíveis.

      Observação

      No caso de falha na validação da assinatura, para evitar novas buscas constantes em caso de ataques com tokens falsos, a nova extração/rearmazenamento em cache da chave pública deve ser baseada em um intervalo de tempo, como 60 minutos, para que as novas buscas ocorram apenas a cada 60 minutos.

    Exemplo

    package sample;
     
    import java.net.MalformedURLException;
    import java.net.URL;
     
    import com.nimbusds.jose.JWSAlgorithm;
    import com.nimbusds.jose.jwk.source.JWKSource;
    import com.nimbusds.jose.jwk.source.RemoteJWKSet;
    import com.nimbusds.jose.proc.JWSKeySelector;
    import com.nimbusds.jose.proc.JWSVerificationKeySelector;
    import com.nimbusds.jose.proc.SecurityContext;
    import com.nimbusds.jwt.JWTClaimsSet;
    import com.nimbusds.jwt.proc.ConfigurableJWTProcessor;
    import com.nimbusds.jwt.proc.DefaultJWTProcessor;
     
    public class TokenValidation {
     
        public static void main(String[] args) {
            try {
                String tokenValue = "eyJ4NXQjUzI1....W9J4oQ";
         
                ConfigurableJWTProcessor jwtProcessor = new DefaultJWTProcessor();
     
                // change t
                JWKSource keySource = new RemoteJWKSet(new URL("https://<domainURL>/admin/v1/SigningCert/jwk"));
     
                // The expected JWS algorithm of the token (agreed out-of-band)
                JWSAlgorithm expectedJWSAlg = JWSAlgorithm.RS256;
     
                // Configure the JWT processor with a key selector to feed matching public
                // RSA keys sourced from the JWK set URL
                JWSKeySelector keySelector = new JWSVerificationKeySelector(expectedJWSAlg, keySource);
                jwtProcessor.setJWSKeySelector(keySelector);
     
                // Process the token
                SecurityContext ctx = null; // optional context parameter, not required here
                JWTClaimsSet claimsSet = jwtProcessor.process(tokenValue, ctx);
                // Print out the token claims set
                System.out.println(claimsSet.toJSONObject());
                 
     
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
     
    }
  4. Verifique se o valor da reivindicação do Identificador do Emissor (iss) corresponde exatamente ao valor da reivindicação do iss (emissor): https://<domainURL>/

Validando Tokens de Acesso

As transações bem-sucedidas do OAuth exigem que o Servidor de Autorização do domínio de identidades OAuth emita tokens de acesso para uso na autenticação de uma chamada de API. Um token de acesso representa uma autorização emitida para o aplicativo cliente que contém credenciais usadas para acessar recursos protegidos do OAuth. Para validar um token de acesso emitido do ponto final de Autorização, o cliente do aplicativo deve fazer o seguinte:
Observação

Consulte a tabela Token de Acesso.
  1. Verifique se o token de acesso está devidamente assinado pelo emissor.

    • Recupere o certificado público do tenant no ponto final SigningCert/jwk (por exemplo, https://acme.identity.oraclecloud.com/admin/v1/SigningCert/jwk).

      Observação

      Como os domínios de identidades alteram as chaves públicas com pouca frequência, você pode armazenar em cache as chaves públicas e, na grande maioria dos casos, executar com eficiência a validação local. Isso requer recuperar e analisar certificados e fazer as chamadas de criptografia apropriadas para verificar a assinatura:
    • Use qualquer biblioteca JWT disponível para validar, por exemplo, a Biblioteca JWT Nimbus do Connect2id para Java. Consulte JWT para obter uma lista de bibliotecas disponíveis.

    • Informe o certificado para a respectiva API da biblioteca, por exemplo, usando a API Nimbus SignedJWT:

      PublicKey = x509Certificate.getPublicKey();
      // verify the signature.
      JWSVerifier verifier = new RSASSAVerifier((RSAPublicKey) (publicKey));
      boolean isTokenValid = signedJWT.verify(verifier);
      
      Observação

      No caso de falha na validação da assinatura, para evitar novas buscas constantes em caso de ataques com tokens falsos, a nova extração/rearmazenamento em cache da chave pública deve ser baseada em um intervalo de tempo, como 60 minutos, para que as novas buscas ocorram apenas a cada 60 minutos.
  2. Verifique se o valor da reivindicação do Identificador do Emissor (iss) corresponde exatamente ao valor da reivindicação do iss (emissor): https://<domainURL>/

  3. Verifique se o token de acesso tem a reivindicação de público (aud), conforme solicitado pelo cliente. O valor da reivindicação aud muda de escopo para escopo. A reivindicação aud será um array se houver vários públicos e será uma string se houver apenas um público.

    A reivindicação aud é o público principal do servidor de recursos do Aplicativo de domínio de identidades do IAM. Se houver algum público secundário definido no Aplicativo de domínio de identidades do IAM, ele também será adicionado como parte da reivindicação aud. Como parte da validação do token de acesso, o servidor deverá permitir o acesso se um dos valores no array aud fizer sentido para o servidor de recursos.

  4. Verifique se o horário atual é anterior ao horário representado pela reivindicação de tempo de expiração (exp).

  5. Verifique se o token de acesso está autorizado a executar a operação com base no conteúdo da reivindicação do escopo. A reivindicação de escopo no token de acesso é uma lista de strings separadas por espaço.