How to handle callback in .NET

[mkay]

I have an issue where redirecting user after authentication is not working properly

currently testing in local environment

when user first goes to login page (http://localhost:44394/acount/login
), Auth0 universal login page will appear

// AccountController.cs
public async Task<ActionResult> Login() {
 var domain = ProLib.AppSettings.Get<string>("Auth0_Domain");
            var clientId = ProLib.AppSettings.Get<string>("Auth0_ClientId");
            var redirectUri = ProLib.AppSettings.Get<string>("Auth0_RedirectUri");
            var root = "http://localhost:44394/";
            var client = new AuthenticationApiClient(domain);

            var authorizationUrl = client.BuildAuthorizationUrl()
              .WithResponseType(AuthorizationResponseType.Code)
              .WithClient(clientId)
              .WithConnection("Username-Password-Authentication")
              .WithRedirectUrl(root + redirectUri)
              .WithScope("openid offline_access profile email")
              .Build();

            Console.WriteLine(authorizationUrl);

            return Redirect(authorizationUrl.AbsoluteUri);
}

after user inputs credentials, is redirected to http://localhost:44394/Account/Callback?code=j1-zo7ZEZ7kVEPlkYyxZfTfuCoR5VMn1xeeeeeeeeee

and below is my code to handle after redirection

// AccountController.cs
public async Task<IActionResult> Callback(string code)
        {
            var domain = ProLib.AppSettings.Get<string>("Auth0_Domain");
            var clientId = ProLib.AppSettings.Get<string>("Auth0_ClientId");
            var clientSecret = ProLib.AppSettings.Get<string>("Auth0_ClientSecret");
            var redirectUri = ProLib.AppSettings.Get<string>("Auth0_RedirectUri");
            var root = "http://localhost:44394/";
            var client = new AuthenticationApiClient(domain);

            var request = new AuthorizationCodeTokenRequest()
            {
                ClientId = clientId,
                ClientSecret = clientSecret,
                Code = code,
                RedirectUri = root + redirectUri
            };

          
                return RedirectToAction("Index", "Home", new { area = "App" });
            }
            catch (Exception)
            {
            
                return RedirectToAction("Index", "Home", new { area = "App" });
            }
        }

and I got the error as below
This site can’t be reachedThe connection was reset.

callback url http://localhost:44394/account/callback is whitelisted and not sure how to handle further logic to send auth code and get accesstoken

[spoudel]

Does the code even reach the controller? Have you tried putting breakpoint on the callback controller?

On the side note, I suggest keeping the authentication profile info in the a separate class, like a Startup.cs. Would make your code non repetitive.

[mkay]

no it doesn’t reach the callback controller.
what am I missing here?

[spoudel]

if you just change the redirect uri to be home/index, it should work just fine . Its because I see that you have done nothing but redirect on the callback controller. You would need to add [Authorize] attribute or check if Request is authenticated in the Index action.
Also, I have seen that Auth0’s allow list of callback urls are case sensitive

[mkay]

Thanks for the reply
I have a question as I have little experience in .NET development

Could you tell me the reason why it doesn’t reach “Callback()” controller in my code? and where is that logic that exchanges auth code to accessToken ? in an example auth0 project, baseurl/callback was the redirect URL. and there was no callback controller at all. is it handled by auth0 behind the scene?

[spoudel]

HAR logs would be helpful to determine what is actually going on and why your Callback() controller has not been reached. Make sure you hide sensitive information from HAR if you plan to post it.
If Auth0 doesnt find any “return to”, “baseurl/callback” is the default value. In your case, supplying “return to” or the “redirect uri”, and adding that url in the list of allowed callback urls could solve the problem.