Validación de token

¿Por qué validamos los 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. Al utilizar la identidad basada en reclamaciones, 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. Para poder utilizar la información o confiar en ella como una afirmación que el usuario 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 estos 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 de 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, userinfo y claves públicas. Puede recuperar el documento de detección de un servicio de conexión OpenID de un dominio de identidad de IAM desde: https://<domainURL>/.well-known/openid-configuration.

Consulte los documentos de detección de Oracle Identity Cloud Service OpenID.

Validación de tokens de identidad

Un token de identidad (ID) es un token autónomo protegido por la integridad (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 el token de ID de un usuario que había capturado anteriormente, la aplicación debería 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 a 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 manejen de forma segura enviándolos solo a través de HTTPS y solo utilizando datos POST o en cabeceras de solicitud. Si los almacena en su servidor, también debe almacenarlos de forma segura.
  1. Verifique 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 debe rechazarse si el token de ID no muestra al cliente como un público válido o si contiene públicos adicionales en los que el cliente no confía.

  2. Compruebe que la hora actual es anterior a la hora representada por la reclamación de tiempo 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 encontrados en el URI especificado en el campo jwks_uri del documento de detección.
    • Recupere el certificado público del inquilino del 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 las bibliotecas de JWT disponibles 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 debe basarse en un intervalo de tiempo, como 60 minutos, para que las recuperaciones solo se produzcan 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 de 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 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 haya firmado correctamente el token de acceso.

    • Recupere el certificado público del inquilino del 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 las bibliotecas de JWT disponibles 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 debe basarse en un intervalo de tiempo, como 60 minutos, para que las recuperaciones solo se produzcan 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 de iss (emisor): https://<domainURL>/

  3. Verifique que el token de acceso tiene la reclamación de público (aud) solicitada 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 públicos 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. Compruebe que la hora actual es anterior a la hora representada por la reclamación de tiempo 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.