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.
-
Verifique se o valor da reivindicação de público-alvo (
aud
) contém o valorclient_id
do aplicativo. A reivindicaçãoaud
(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. -
Verifique se a hora atual é anterior à hora representada pela reivindicação de tempo de expiração (
exp
). -
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(); } } }
-
-
Verifique se o valor da reivindicação do Identificador do Emissor (
iss
) corresponde exatamente ao valor da reivindicaçãoiss
(emissor):https://<domainURL>/
Validando tokens de acesso
-
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.
-
-
Verifique se o valor da reivindicação do Identificador do Emissor (
iss
) corresponde exatamente ao valor da reivindicaçãoiss
(emissor):https://<domainURL>/
-
Verifique se o token de acesso tem a reivindicação de público-alvo (
aud
), conforme solicitado pelo cliente. O valor da reivindicaçãoaud
é alterado do escopo para o escopo. A reivindicaçãoaud
é 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çãoaud
. Como parte da validação do token de acesso, o servidor deverá permitir o acesso se um dos valores no arrayaud
fizer sentido para o servidor de recursos. -
Verifique se a hora atual é anterior à hora representada pela reivindicação de tempo de expiração (
exp
). -
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.