Convalida token

Perché convalidiamo i token? Quando l'applicazione Web controlla direttamente le credenziali, verifica che il nome utente e la password presentati corrispondano a ciò che si mantiene. Quando si utilizza un'identità basata su richieste di rimborso, tale mansione viene affidata a un provider di identità.

La responsabilità passa dalla verifica delle credenziali raw alla verifica che il richiedente abbia eseguito l'autenticazione tramite il provider di identità preferito. Il provider di identità rappresenta l'autenticazione riuscita mediante l'emissione di un token. Prima di poter utilizzare le informazioni o fare affidamento su di esse come asserzione che l'utente ha autenticato, è necessario convalidarle.

OpenID Documento di ricerca automatica

Il protocollo OpenID Connect 1.0 è un livello di identità semplice al di sopra del protocollo OAuth 2.0 che richiede l'uso di più endpoint per l'autenticazione degli utenti e per la richiesta di risorse che includono informazioni utente, token e chiavi pubbliche. Per facilitare la ricerca automatica degli endpoint da utilizzare, OpenID Connect consente di utilizzare un documento di ricerca automatica, ovvero un documento JSON trovato in una posizione ben nota. Questo documento di ricerca automatica contiene coppie chiave/valore che forniscono dettagli sulla configurazione del provider OpenID Connect, inclusi gli URI degli endpoint di autorizzazione, token, informazioni utente e chiavi pubbliche. È possibile recuperare il documento di ricerca automatica per il servizio OpenID Connect di un dominio di Identity IAM dal seguente indirizzo: https://<domainURL>/.well-known/openid-configuration.

Consulta la documentazione di Oracle Identity Cloud Service OpenID Discovery.

Convalida dei token di identità

Un token ID (Identity) è un token self-contained protetto dall'integrità (in formato JSON Web Token) che contiene richieste relative all'utente finale. Rappresenta la sessione di un utente autenticato. Pertanto, il token deve essere convalidato prima che un'applicazione possa considerare attendibile il contenuto del token ID. Ad esempio, se un utente malintenzionato ha ripetuto il token ID di un utente acquisito in precedenza, l'applicazione dovrebbe rilevare che il token è stato ripetuto o è stato utilizzato dopo la scadenza e negare l'autenticazione.

Il token ID è definito nello standard OpenID Connect ed è l'estensione primaria che OpenID Connect fa a OAuth 2.0 per abilitare l'autenticazione. I token ID sono sensibili e possono essere utilizzati in modo improprio se intercettati. Assicurarsi che questi token siano gestiti in modo sicuro inviandoli solo tramite HTTPS e solo utilizzando i dati POST o all'interno delle intestazioni delle richieste. Se li memorizzi sul tuo server, devi anche memorizzarli in modo sicuro.
  1. Verificare che il valore della richiesta di audience (aud) contenga il valore client_id dell'applicazione. Il claim aud (audience) può contenere un array con più elementi. Il token ID deve essere rifiutato se il token ID non elenca il client come audience valida o se contiene audience aggiuntive non attendibili dal client.

  2. Verificare che l'ora corrente sia precedente all'ora rappresentata dalla richiesta di scadenza (exp).

  3. Verificare che il token ID sia firmato correttamente dall'emittente. I token emessi dal dominio di Identity IAM vengono firmati utilizzando uno dei certificati trovati nell'URI specificato nel campo jwks_uri del documento di ricerca automatica.
    • Recuperare il certificato pubblico del tenant dall'endpoint SigningCert/jwk (ad esempio, https://acme.identity.oraclecloud.com/admin/v1/SigningCert/jwk).

      Nota

      Poiché i domini di Identity cambiano le chiavi pubbliche di rado, è possibile inserire le chiavi pubbliche nella cache e, nella stragrande maggioranza dei casi, eseguire in modo efficiente la convalida locale. Ciò richiede il recupero e l'analisi dei certificati e l'esecuzione delle chiamate crittografiche appropriate per controllare la firma:
    • Utilizzare le librerie JWT disponibili per convalidare, ad esempio, la libreria JWT Nimbus di Connect2id per Java. Per un elenco delle librerie disponibili, vedere JWT.

      Nota

      In caso di errore di convalida della firma, per evitare reincroci costanti in caso di attacchi con token fasulli, il reinserimento/reinserimento nella cache della chiave pubblica deve essere basato su un intervallo di tempo, ad esempio 60 minuti, in modo che i reincroci avvengano solo ogni 60 minuti.

    Esempio

    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. Verificare che il valore della richiesta di identificazione emittente (iss) corrisponda esattamente al valore della richiesta di rimborso iss (emittente): https://<domainURL>/

Convalida dei token di accesso

Le transazioni OAuth riuscite richiedono che il server di autorizzazione del dominio di Identity OAuth emetta token di accesso da utilizzare per autenticare una chiamata API. Un token di accesso rappresenta un'autorizzazione rilasciata all'applicazione client contenente le credenziali utilizzate per accedere alle risorse OAuth protette. Per convalidare un token di accesso emesso dall'endpoint di autorizzazione, il client dell'applicazione deve effettuare le operazioni riportate di seguito.
Nota

Vedere la tabella Token di accesso.
  1. Verificare che il token di accesso sia firmato correttamente dall'emittente.

    • Recuperare il certificato pubblico del tenant dall'endpoint SigningCert/jwk (ad esempio, https://acme.identity.oraclecloud.com/admin/v1/SigningCert/jwk).

      Nota

      Poiché i domini di Identity cambiano le chiavi pubbliche di rado, è possibile inserire le chiavi pubbliche nella cache e, nella stragrande maggioranza dei casi, eseguire in modo efficiente la convalida locale. Ciò richiede il recupero e l'analisi dei certificati e l'esecuzione delle chiamate crittografiche appropriate per controllare la firma:
    • Utilizzare le librerie JWT disponibili per convalidare, ad esempio, la libreria JWT Nimbus di Connect2id per Java. Per un elenco delle librerie disponibili, vedere JWT.

    • Passare il certificato all'API della rispettiva libreria, ad esempio utilizzando l'API SignedJWT di Nimbus:

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

      In caso di errore di convalida della firma, per evitare reincroci costanti in caso di attacchi con token fasulli, il reinserimento/reinserimento nella cache della chiave pubblica deve essere basato su un intervallo di tempo, ad esempio 60 minuti, in modo che i reincroci avvengano solo ogni 60 minuti.
  2. Verificare che il valore della richiesta di identificazione emittente (iss) corrisponda esattamente al valore della richiesta di rimborso iss (emittente): https://<domainURL>/

  3. Verificare che il token di accesso disponga della richiesta di audience (aud) come richiesto dal client. Il valore della richiesta aud cambia da ambito a ambito. La richiesta aud è un array se sono presenti più audience ed è una stringa se è presente un solo audience.

    La richiesta aud è l'audience principale del server delle risorse dell'applicazione del dominio di Identity IAM. Se nell'applicazione del dominio di Identity IAM sono definiti segmenti di pubblico secondari, questi vengono aggiunti anche come parte della richiesta aud. Nell'ambito della convalida del token di accesso, il server deve consentire l'accesso se uno dei valori nell'array aud ha senso per il server delle risorse.

  4. Verificare che l'ora corrente sia precedente all'ora rappresentata dalla richiesta di scadenza (exp).

  5. Verificare che il token di accesso sia autorizzato a eseguire l'operazione in base al contenuto della richiesta di ambito. La richiesta di ambito nel token di accesso è una lista di stringhe separate da spazi.