Se utilizzi HTTPS / SSL e ti fidi dei tuoi endpoint, questo è abbastanza sicuro per i tuoi scopi, perché il parametro get verrà crittografato come parte della stringa di query, quindi l'acquisizione del traffico non è un problema.
Gli hash "segreti" molto probabilmente finiranno nei registri del server web del server web quali server della tua applicazione web, ma se controlli questi log, allora per il tuo livello di sicurezza desiderato probabilmente non è un problema.
Ovviamente dovrai fidarti anche di tutti i servizi che memorizzano questi URL (segnalibri del browser, servizi cloud, ecc., ma vedi che tutto va bene). Pensavo che il rischio maggiore fosse qui (ad esempio, uno dei tuoi utenti accede utilizzando un computer pubblico, e il prossimo utente di quel computer pubblico guarda la cronologia del browser, fa clic sul link e ha accesso ai tuoi dati protetti).
Se usi HTTP non crittografato, i tuoi hash segreti finiranno anche nei log del server proxy e praticamente chiunque possa intercettare la tua connessione avrà molte possibilità di catturare i segreti.
Tuttavia , farei direttamente l'autenticazione GET param se non mi interessa molto della segretezza e dell'integrità dei dati che gli hash segreti dovrebbero proteggere (in pratica se volessi tenere a bada le orde di stupidi vandali, ma non pensavo che una persona determinata potesse essere interessata abbastanza ai miei dati per tentare di accedervi, e non aveva alcun problema se si fosse scoperto che avevo torto).
Un modo molto semplice per migliorare considerevolmente la sicurezza del tuo schema di autenticazione sarebbe quello di far scadere i token segreti, o ancora meglio, di trattarli come password monouso. Dare a ciascun utente un elenco di token, da utilizzare uno dopo l'altro. Questo non richiede molto codice sul lato server e risolve il problema di uno dei tuoi utenti che lascia / pubblica inavvertitamente il suo token segreto da qualche parte.