2 add explicit answers to the questions
source | link

It is a good idea to move in the direction of least privilege authorization, so if use of an admin API involves impersonating specific users, there should be a credential that represents the specific user under impersonation.

That said, I would encourage consideration of practices other than taking a permanent admin key and hashing it with a permanent public user attribute to produce a user-specific credential. The most important weakness of that user-specific credential is that it is permanent.

Consider moving in the direction where individual actions are granted specific temporary credentials, so one is not doing any actual business with an admin key. So: create an API that takes the admin key and an action- like impersonate a user, though actions can include admin actions that are not user specific as well- and create a temporary token with only those privileges. Require the use of those limited privilege tokens and disallow the use of full-privilege admin key in any specific privileged operation.

There is of course a lot of prior art here, and lots of specific considerations that apply to specific situations, which one may or may not be inclined to dive into. Generally speaking, though, moving in the direction of the use of temporary constrained credentials ratheris better than constraining permanent broad credentials.

In sum:

Is this a known technique?

Yes, there are many ways to constrain a token for use in a specific circumstance. Can add the email address as another header and hash the secret/email pair. See also JWTs. Many, many permutations to achieve similar ends.

Is this a decent security improvement? 

It is better to use a goodtoken with fewer capabilities than one with more, so, it represents an improvement, but as below, there are much better improvements, so while it is an improvement, it's not a decent improvement.

Any downsides? 

The permanent nature of the tokens is undesirable. Someone who gets one user's token can presumably get other user tokens, and since they are based on permanent attributes- a permanent secret and the user email- they can be used by the attacker forever. Better to move in the direction of adopting time-limited tokens, which can also be constrained to permit only specific functions.

It is a good idea to move in the direction of least privilege authorization, so if use of an admin API involves impersonating specific users, there should be a credential that represents the specific user under impersonation.

That said, I would encourage consideration of practices other than taking a permanent admin key and hashing it with a permanent public user attribute to produce a user-specific credential. The most important weakness of that user-specific credential is that it is permanent.

Consider moving in the direction where individual actions are granted specific temporary credentials, so one is not doing any actual business with an admin key. So: create an API that takes the admin key and an action- like impersonate a user, though actions can include admin actions that are not user specific as well- and create a temporary token with only those privileges. Require the use of those limited privilege tokens and disallow the use of full-privilege admin key in any specific privileged operation.

There is of course a lot of prior art here, and lots of specific considerations that apply to specific situations, which one may or may not be inclined to dive into. Generally speaking, though, moving in the direction of the use of temporary constrained credentials rather than permanent broad credentials is a good one.

It is a good idea to move in the direction of least privilege authorization, so if use of an admin API involves impersonating specific users, there should be a credential that represents the specific user under impersonation.

That said, I would encourage consideration of practices other than taking a permanent admin key and hashing it with a permanent public user attribute to produce a user-specific credential. The most important weakness of that user-specific credential is that it is permanent.

Consider moving in the direction where individual actions are granted specific temporary credentials, so one is not doing any actual business with an admin key. So: create an API that takes the admin key and an action- like impersonate a user, though actions can include admin actions that are not user specific as well- and create a temporary token with only those privileges. Require the use of those limited privilege tokens and disallow the use of full-privilege admin key in any specific privileged operation.

There is of course a lot of prior art here, and lots of specific considerations that apply to specific situations, which one may or may not be inclined to dive into. Generally speaking, though, moving in the direction of the use of temporary credentials is better than constraining permanent credentials.

In sum:

Is this a known technique?

Yes, there are many ways to constrain a token for use in a specific circumstance. Can add the email address as another header and hash the secret/email pair. See also JWTs. Many, many permutations to achieve similar ends.

Is this a decent security improvement? 

It is better to use a token with fewer capabilities than one with more, so, it represents an improvement, but as below, there are much better improvements, so while it is an improvement, it's not a decent improvement.

Any downsides? 

The permanent nature of the tokens is undesirable. Someone who gets one user's token can presumably get other user tokens, and since they are based on permanent attributes- a permanent secret and the user email- they can be used by the attacker forever. Better to move in the direction of adopting time-limited tokens, which can also be constrained to permit only specific functions.

1
source | link

It is a good idea to move in the direction of least privilege authorization, so if use of an admin API involves impersonating specific users, there should be a credential that represents the specific user under impersonation.

That said, I would encourage consideration of practices other than taking a permanent admin key and hashing it with a permanent public user attribute to produce a user-specific credential. The most important weakness of that user-specific credential is that it is permanent.

Consider moving in the direction where individual actions are granted specific temporary credentials, so one is not doing any actual business with an admin key. So: create an API that takes the admin key and an action- like impersonate a user, though actions can include admin actions that are not user specific as well- and create a temporary token with only those privileges. Require the use of those limited privilege tokens and disallow the use of full-privilege admin key in any specific privileged operation.

There is of course a lot of prior art here, and lots of specific considerations that apply to specific situations, which one may or may not be inclined to dive into. Generally speaking, though, moving in the direction of the use of temporary constrained credentials rather than permanent broad credentials is a good one.