Resend email verification without revealing client_secret in the client?

Help
1

Hi Everyone, any help is greatly appreciated! Basically i am looking to have a button on my app which will re-send the email verification to a user. The problem is that it seems we need to use the management api to do this with endpoint /api/v2/jobs/verification-email and to get a management API token, i need to send the client_secret.

  1. I can send a call to my own api which then calls the send email verification on the management api, thus using my api as a “middleman” so that the client secret isn’t exposed.

  2. I tried adding myauth0domain/api/v2 as an audience when i create my auth0 object, however the email verification requires “update:users” as a scope, and according to the documentation it only allows me to add the following scopes:

  • read:current_user
  • update:current_user_identities
  • create:current_user_metadata
  • update:current_user_metadata
  • delete:current_user_metadata
  • create:current_user_device_credentials
  • delete:current_user_device_credentials

Option2 is ideal but as stated above, it doesn’t allow the correct scope according to the documentation. I just want the easiest way to accomplish this without having to expose my client_secret. Would be great if there was a management token that only affected that one user and allowed me to define any scopes i wanted etc.

Thank you ahead of time to whomever decides to save me from continuing to bang my head on the wall with this.

1 Like
3

We’re facing the same issue. We’re trying to strictly limit our use of the client secret and also limit the scopes were requesting. Having to get update:users scope seems overkill for re-sending the verification email. I’ve submitted this as a feature request using the feedback form, but haven’t heard anything about it yet.

4

Hey @shanesaravia!

Sorry for the delay in response. We’re trying to do our best in helping our community developers however sometimes we’re people constraint and are not able to handle all questions effectively. Thanks a lot for understanding and sorry for the delay once again!

@eric.jutrzenka please let me know if our team doesn’t reach out back to you shortly regarding the future request and I’ll help to push it forward :slight_smile:

5

I was searching for solutions to this again and ended up finding my old post! We’ve been holding off on implementing this in the hope that something might change.

I don’t think I did hear anything back on this.

Requiring update:users for resending verification emails seems to be in disagreement with the principle of least privilege. Would love to know if I’m wrong about this!

We’re considering implementing a back-end service to work around this, but that doesn’t solve the least privilege problem and increases our exposure to the risk of disclosing our client secret.

2 Likes
6

Has there been any news on this? we are in the same spot and trying to figure out a solution.

7

It doesn’t seem so. What I would suggest - go to our feedback site to provide direct feedback for a feature request to our product team and make sure to provide your usecase and context. They should reach out to you within 10 business days: