Validación de Token

¿Por qué validamos tokens? Cuando la aplicación web comprueba las credenciales directamente, verifica que el nombre de usuario y la contraseña que se presentan corresponden con lo que mantiene. Cuando se utiliza la identidad basada en reclamaciones, se subcontrata ese trabajo a un proveedor de identidad.

La responsabilidad pasa de verificar las credenciales raw a verificar que el solicitante ha pasado por el proveedor de identidad preferido y se ha autenticado correctamente. El proveedor de identidad representa una autenticación correcta mediante la emisión de un token. Antes de poder utilizar la información o confiar en ella como afirmación de que el usuario se ha autenticado, debe validarla.

OpenID Documento de Detección

El protocolo OpenID Connect 1.0 es una capa de identidad simple sobre el protocolo OAuth 2.0 que requiere el uso de varios puntos finales para autenticar usuarios y para solicitar recursos que incluyen información de usuario, tokens y claves públicas. Para ayudar a detectar cuáles son los puntos finales que debe utilizar, OpenID Connect le permite utilizar un documento de detección, que es un documento JSON que se encuentra en una ubicación conocida. Este documento de detección contiene pares clave/valor que proporcionan detalles sobre la configuración del proveedor de Connect OpenID, incluidos los URI de los puntos finales de autorización, token, información de usuario y claves públicas. Puede recuperar el documento de detección para un servicio de conexión OpenID de un dominio de identidad de IAM desde: https://<domainURL>/.well-known/openid-configuration.

Consulte la documentación de Detección de Oracle Identity Cloud Service OpenID.

Validación de tokens de identidad

Un token de identidad (ID) es un token protegido por integridad y autónomo (en formato de token web JSON) que contiene reclamaciones sobre el usuario final. Representa la sesión de un usuario autenticado. Por lo tanto, el token se debe validar antes de que una aplicación pueda confiar en el contenido del token de ID. Por ejemplo, si un atacante malicioso reprodujo un token de ID de usuario que había capturado anteriormente, la aplicación debe detectar que el token se ha reproducido o se ha utilizado después de que haya caducado y denegar la autenticación.

El token de ID se define en el estándar OpenID Connect y es la extensión principal que OpenID Connect realiza en OAuth 2.0 para activar la autenticación. Los tokens de ID son confidenciales y se pueden utilizar incorrectamente si se interceptan. Asegúrese de que estos tokens se gestionan de forma segura enviándolos solo a través de HTTPS y solo mediante el uso de datos POST o en cabeceras de solicitud. Si los almacena en su servidor, también debe almacenarlos de forma segura.
  1. Compruebe que el valor de la reclamación de público (aud) contiene el valor client_id de la aplicación. La reclamación aud (audiencia) puede contener una matriz con más de un elemento. El token de ID se debe rechazar si el token de ID no muestra al cliente como un público válido o si contiene públicos adicionales de los que el cliente no confía.

  2. Verifique que la hora actual sea anterior a la hora representada por la reclamación de la hora de caducidad (exp).

  3. Verifique que el emisor haya firmado correctamente el token de ID. Los tokens emitidos por el dominio de identidad de IAM se firman mediante uno de los certificados que se encuentran en el URI especificado en el campo jwks_uri del documento de detección.
    • Recupere el certificado público del inquilino desde el punto final SigningCert/jwk (por ejemplo, https://acme.identity.oraclecloud.com/admin/v1/SigningCert/jwk).

      Nota

      Dado que los dominios de identidad cambian las claves públicas con poca frecuencia, puede almacenar en caché las claves públicas y, en la gran mayoría de los casos, realizar de forma eficaz la validación local. Esto requiere recuperar y analizar certificados y realizar las llamadas criptográficas adecuadas para comprobar la firma:
    • Utilice cualquier biblioteca de JWT disponible para validar, por ejemplo, la biblioteca Nimbus JWT de Connect2id para Java. Consulte JWT para obtener una lista de las bibliotecas disponibles.

      Nota

      En caso de fallo de validación de firma, para evitar recuperaciones constantes en caso de ataques con tokens falsos, la recuperación/realmacenamiento en caché de la clave pública se debe basar en un intervalo de tiempo, como 60 minutos, para que las recuperaciones solo se realicen cada 60 minutos.

    Ejemplo

    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 que el valor de la reclamación del identificador de emisor (iss) coincida exactamente con el valor de la reclamación iss (emisor): https://<domainURL>/

Validación de tokens de acceso

Las transacciones OAuth correctas requieren que el servidor de autorización OAuth del dominio de identidad emita tokens de acceso para su uso en la autenticación de una llamada de API. Un token de acceso representa una autorización emitida a la aplicación cliente que contiene las credenciales utilizadas para acceder a los recursos OAuth protegidos. Para validar un token de acceso emitido desde el punto final de autorización, el cliente de aplicación debe hacer lo siguiente:
Nota

Consulte la tabla Token de acceso.
  1. Verifique que el emisor firme correctamente el token de acceso.

    • Recupere el certificado público del inquilino desde el punto final SigningCert/jwk (por ejemplo, https://acme.identity.oraclecloud.com/admin/v1/SigningCert/jwk).

      Nota

      Dado que los dominios de identidad cambian las claves públicas con poca frecuencia, puede almacenar en caché las claves públicas y, en la gran mayoría de los casos, realizar de forma eficaz la validación local. Esto requiere recuperar y analizar certificados y realizar las llamadas criptográficas adecuadas para comprobar la firma:
    • Utilice cualquier biblioteca de JWT disponible para validar, por ejemplo, la biblioteca Nimbus JWT de Connect2id para Java. Consulte JWT para obtener una lista de las bibliotecas disponibles.

    • Transfiera el certificado a la API de la biblioteca correspondiente, por ejemplo, mediante la API SignedJWT de Nimbus:

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

      En caso de fallo de validación de firma, para evitar recuperaciones constantes en caso de ataques con tokens falsos, la recuperación/realmacenamiento en caché de la clave pública se debe basar en un intervalo de tiempo, como 60 minutos, para que las recuperaciones solo se realicen cada 60 minutos.
  2. Verifique que el valor de la reclamación del identificador de emisor (iss) coincida exactamente con el valor de la reclamación iss (emisor): https://<domainURL>/

  3. Verifique que el token de acceso tenga la reclamación de público (aud) según lo solicitado por el cliente. El valor de la reclamación aud cambia de ámbito a ámbito. La reclamación aud es una matriz si hay varios públicos y es una cadena si solo hay un público.

    La reclamación aud es el público principal del servidor de recursos de la aplicación de dominio de identidad de IAM. Si hay destinatarios secundarios definidos en la aplicación de dominio de identidad de IAM, también se agregan como parte de la reclamación aud. Como parte de la validación del token de acceso, el servidor debe permitir el acceso si uno de los valores de la matriz aud tiene sentido para el servidor de recursos.

  4. Verifique que la hora actual sea anterior a la hora representada por la reclamación de la hora de caducidad (exp).

  5. Verifique que el token de acceso esté autorizado para realizar la operación en función del contenido de la reclamación de ámbito. La reclamación de ámbito en el token de acceso es una lista de cadenas separadas por espacios.