È una buona idea spostarsi nella direzione dell'autorizzazione di privilegi minimi, quindi se l'uso di un'API di amministrazione comporta la rappresentazione di utenti specifici, dovrebbe esserci una credenziale che rappresenta l'utente specifico sotto rappresentazione.
Detto questo, vorrei incoraggiare l'esame di pratiche diverse dall'assunzione di una chiave di amministrazione permanente e l'hashing con un attributo utente pubblico permanente per produrre una credenziale specifica dell'utente. Il punto debole più importante di quella credenziale specifica dell'utente è che è permanente.
Considerare lo spostamento nella direzione in cui alle singole azioni vengono concesse specifiche credenziali temporanee, quindi non si sta facendo business con una chiave di amministrazione. Quindi: crea un'API che accetta la chiave di amministrazione e un'azione simile a quella di impersonare un utente, sebbene le azioni possano includere azioni di amministrazione che non sono specifiche dell'utente e creare un token temporaneo con solo questi privilegi. Richiedere l'uso di questi token di privilegio limitato e non consentire l'uso della chiave di amministrazione di privilegio completo in qualsiasi operazione privilegiata specifica.
Naturalmente qui c'è molta arte nota e molte considerazioni specifiche che si applicano a situazioni specifiche, alle quali si può o non si può inclinarsi di tuffarsi. In generale, però, muoversi nella direzione dell'uso delle credenziali temporanee è meglio che limitare le credenziali permanenti.
In sum:
Is this a known technique?
Sì, ci sono molti modi per vincolare un token per l'uso in una circostanza specifica. Può aggiungere l'indirizzo email come un'altra intestazione e cancellare la coppia segreta / email. Vedi anche JWT. Molte, molte permutazioni per raggiungere fini simili.
Is this a decent security improvement?
È meglio usare un token con meno funzionalità di uno con più, quindi rappresenta un miglioramento , ma come sotto, ci sono miglioramenti molto migliori, quindi mentre è un miglioramento, è non un miglioramento decente .
Any downsides?
La natura permanente dei token non è desiderabile. Qualcuno che riceve un token di un utente può presumibilmente ricevere altri token utente e poiché si basano su attributi permanenti, un segreto permanente e l'email dell'utente, possono essere utilizzati dall'attaccante per sempre. Meglio muoversi nella direzione dell'adozione di token a tempo limitato, che possono anche essere limitati per consentire solo funzioni specifiche.