Es una buena idea moverse en la dirección de la autorización de privilegios mínimos, por lo que si el uso de una API de administración implica hacerse pasar por usuarios específicos, debe haber una credencial que represente al usuario específico bajo la suplantación.
Dicho esto, recomendaría que se consideren otras prácticas además de tomar una clave de administración permanente y aplicarla con un atributo de usuario público permanente para generar una credencial específica para el usuario. La debilidad más importante de esa credencial específica del usuario es que es permanente.
Considere la posibilidad de moverse en la dirección en la que se otorgan las credenciales temporales específicas a las acciones individuales, por lo que uno no está haciendo ningún negocio real con una clave de administrador. Por lo tanto: cree una API que tome la clave de administración y una personificación de acción similar a la de un usuario, aunque las acciones pueden incluir acciones de administración que no son específicas del usuario también, y cree un token temporal con solo esos privilegios. Requiera el uso de esos tokens de privilegio limitado y no permita el uso de la clave de administrador con privilegios completos en ninguna operación privilegiada específica.
Por supuesto, hay mucha técnica anterior aquí, y muchas consideraciones específicas que se aplican a situaciones específicas, en las que uno puede o no estar inclinado a sumergirse. En general, sin embargo, moverse en la dirección del uso de credenciales temporales es mejor que restringir las credenciales permanentes.
En suma:
Is this a known technique?
Sí, hay muchas maneras de restringir un token para su uso en una circunstancia específica. Puede agregar la dirección de correo electrónico como otro encabezado y marcar el par secreto / correo electrónico. Véase también JWTs. Muchas, muchas permutaciones para lograr fines similares.
Is this a decent security improvement?
Es mejor utilizar un token con menos capacidades que uno con más, por lo que representa una mejora , pero como se muestra a continuación, hay mejoras mucho mejores, por lo que si bien es una mejora, es no una mejora decente .
Any downsides?
La naturaleza permanente de los tokens es indeseable. Alguien que obtiene el token de un usuario puede presumiblemente obtener otros tokens de usuario, y como se basan en atributos permanentes, un secreto permanente y el correo electrónico del usuario, el atacante puede utilizarlos para siempre. Es mejor moverse en la dirección de adoptar tokens de tiempo limitado, que también pueden restringirse para permitir solo funciones específicas.