When the email provider is misconfigured, the errors are logged, but one has to log into the Auth0 portal to notice those logs. In my case, I had the wrong API key for SendGrid. When my application was invoking the AuthenticationApiClient.ChangePasswordAsync()
API to issue a password reset, the code was not failing, but the provider was unusable. Auth0 logged the errors, but I was not aware of this happening. After several hours of investigations and ruling absolutely every other option, I have detected the culprit.
Here’s the log:
{
"date": "2022-04-23T20:23:18.852Z",
"type": "fn",
"description": "To: sean.feldman@domain.com",
"connection": "Username-Password-Authentication",
"connection_id": "",
"client_id": "---redacted---",
"details": {
"email_type": "reset_email",
"to": "user@domain.com",
"error": "The provided authorization grant is invalid, expired, or revoked"
},
"log_id": "90020220423202323910263639034699606788278519638008004626",
"_id": "90020220423202323910263639034699606788278519638008004626",
"isMobile": false,
"user_agent": "Other 0.0.0 / Other 0.0.0"
}
Would it be possible for failures that involve an external email provider to send an email notification to the account admin(s) in addition to logging those? This would have saved me a lot of time.
/cc @rueben.tiow @dan.woda
Hi @sean.feldman,
This scenario is addressed directly in the Configure SendGrid as External SMTP Email Provider doc.
Test email
You can now send a test email using the Send Test Email button. If you have configured everything correctly, you will receive a confirmation email. If you do not receive an email after a few minutes, please check your Auth0 logs for any failures.
I would encourage you to follow our docs for setup as they will save you time with these types of headaches.
If you have a Feature Request you can submit them in that category.
Thank you, @dan.woda. I’ve replicated the tenant using the CLI and the key was not assigned properly.
Not sure if the API key was supposed to be copied along with the rest of the settings or not but that’s what happened. I’ve raised a feature request.
I would encourage you to follow our docs for setup as they will save you time with these types of headaches.
That’s what I’ve done when setting it up manually in the original environment. My expectation was that by using the CLI, they configuration of the external email provider will carry over the key as well. If that’s not the case, would be good if the documentation for email provider setup or CLI would indicate so.
1 Like
I did a bit of research and the email provider API key value is considered an environmental variable (likely due to the sensitive nature) and is exported as a ##key##
.
You can replace with this:
1 Like