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 verificar se o solicitante passou pelo provedor de identidades preferido e foi autenticado com sucesso. O provedor de identidades representa uma autenticação bem-sucedida emitindo um token. Antes de usar as informações ou confiar nelas como uma asserção que o usuário autenticou, 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 incluem 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 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 serviço IAM em: https://<domainURL>/.well-known/openid-configuration.

Consulte os documentos do Oracle Identity Cloud Service OpenID Discovery.

Validando Tokens de Identidade

Um Token de Identidade (ID) é um token independente e protegido por 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 reproduzir o Token de ID de um usuário capturado anteriormente, o aplicativo deverá detectar que o token foi reproduzido ou foi usado após a expiração 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 OAuth 2.0 para ativar a autenticação. Os tokens de identificação são sensíveis e podem ser usados incorretamente se interceptados. Certifique-se de que esses tokens sejam tratados com segurança enviando-os apenas por HTTPS e apenas usando dados POST ou dentro de 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-alvo (aud) contém o valor client_id do aplicativo. A reivindicação aud (público-alvo) 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 contiver públicos-alvo adicionais não confiáveis pelo cliente.

  2. Verifique se a hora atual é anterior à hora representada pela reivindicação de tempo de expiração (exp).

  3. Verifique se o Token de ID está assinado corretamente pelo emissor. Os tokens emitidos pelo domínio de identidades do serviço 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 chaves públicas com pouca frequência, você pode armazenar as chaves públicas em cache 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

      Em caso de falha de validação de assinatura, para evitar reencontros constantes em caso de ataques com tokens falsos, o reencontro/reencadeamento da chave pública deve ser baseado em um intervalo de tempo, como 60 minutos, para que reencontros 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 iss (emissor): https://<domainURL>/

Validando tokens de acesso

As transações OAuth bem-sucedidas exigem que o Servidor de Autorização OAuth do domínio de identidades 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 OAuth protegidos. 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 foi assinado corretamente 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 chaves públicas com pouca frequência, você pode armazenar as chaves públicas em cache 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 API da respectiva biblioteca, por exemplo, usando a API SignedJWT do Nimbus:

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

      Em caso de falha de validação de assinatura, para evitar reencontros constantes em caso de ataques com tokens falsos, o reencontro/reencadeamento da chave pública deve ser baseado em um intervalo de tempo, como 60 minutos, para que reencontros 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 iss (emissor): https://<domainURL>/

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

    A reivindicação aud é o público-alvo principal do servidor de recursos do Aplicativo do domínio de identidades do serviço IAM. Se houver públicos secundários definidos no Aplicativo de domínio de identidades do serviço IAM, eles também serão adicionados 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 a hora atual é anterior à hora representada 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 do escopo no token de acesso é uma lista de strings separadas por espaço.