Skip to content

PasswordlessEmailRequest passes literal null when no ClientSecret provided for SPAs #797

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
5 tasks done
mcullifer opened this issue Mar 27, 2025 · 1 comment · Fixed by #800
Closed
5 tasks done
Assignees
Labels
bug This points to a verified bug in the code

Comments

@mcullifer
Copy link

mcullifer commented Mar 27, 2025

Checklist

  • I have looked into the Readme and have not found a suitable solution or answer.
  • I have looked into the API documentation and have not found a suitable solution or answer.
  • I have searched the issues and have not found a suitable solution or answer.
  • I have searched the Auth0 Community forums and have not found a suitable solution or answer.
  • I agree to the terms within the Auth0 Code of Conduct.

Description

I recently updated from 7.0.6 (I know, very old haha) to the most recent version. I noticed we were having errors with PasswordlessEmailRequest used in AuthenticationApiClient.StartPasswordlessEmailFlowAsync(). In my case it was being used for a SPA so I only provided ClientId, Email, Type, and AuthenticationParameters. This was working on 7.0.6 but after updating I started getting an error when using this error in client_secret - invalid type: null (expected string).

Image

The method was called like this

var response = await authApiClient.StartPasswordlessEmailFlowAsync(new PasswordlessEmailRequest
{
    ClientId = settings.WebAppClientId,
    Email = email,
    Type = PasswordlessEmailRequestType.Link,
    AuthenticationParameters = new Dictionary<string, object>
    {
        ["audience"] = settings.Audience,
        ["scope"] = "openid profile email offline_access",
    }
});

After some debugging I realized that when initializing a new PasswordlessEmailRequest the ClientSecret property has a default value of null since it's a string. But after looking at what actually happens in the method

else
{
body.client_secret = request.ClientSecret;
}
it seems like if you do not provide a value in PasswordlessEmailRequest it will pass the literal value of null causing the error. Since this was being used for a SPA I don't need to provide a ClientSecret so this had me stumped for awhile. The fix ended up being initializing it to an empty string

new PasswordlessEmailRequest
{
    ClientId = settings.WebAppClientId,
    ClientSecret = "",
    Email = email,
    Type = PasswordlessEmailRequestType.Link,
    AuthenticationParameters = new Dictionary<string, object>
    {
        ["audience"] = settings.Audience,
        ["scope"] = "openid profile email offline_access",
    }
}

This seems like a confusing default behavior to have so it might be nice if that else statement was instead an else if (!string.isNullOrEmpty(request.ClientSecret). I don't think there's any reason why someone would want to pass the literal value null in any case. I assume this problem would also happen for StartPasswordlessSmsFlowAsync().

Reproduction

  1. Call StartPasswordlessEmailFlowAsync() using a PasswordlessEmailRequest for a SPA application with no ClientSecret value set
  2. Response is an error that client_secret is invalid type null

Additional context

No response

auth0.net version

7.34

.NET version

.NET 9

@mcullifer mcullifer added the bug This points to a verified bug in the code label Mar 27, 2025
@kailash-b kailash-b self-assigned this Apr 3, 2025
@kailash-b
Copy link
Contributor

Hi @mcullifer 👋

Thanks for taking time and bringing this to our notice.
We will look into this and get back in about a week.

Thanks for your patience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This points to a verified bug in the code
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants